1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2 <!-- saved from url=(0059)http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html -->
3 <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4 <title>C++ Standard Library Closed Issues List</title>
5 <style type="text/css">
7 li {text-align:justify}
10 background-color:#E0E0E0;
16 ins {background-color:#A0FFA0}
17 del {background-color:#FFA0A0}
23 <td align="left">Doc. no.</td>
24 <td align="left">D3183=10-0173</td>
27 <td align="left">Date:</td>
28 <td align="left">2010-11-29</td>
31 <td align="left">Project:</td>
32 <td align="left">Programming Language C++</td>
35 <td align="left">Reply to:</td>
36 <td align="left">Alisdair Meredith <<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>></td>
39 <h1>C++ Standard Library Closed Issues List (Revision D73)</h1>
40 <p>Revised 2010-11-29 at 10:11:56 UTC</p>
42 <p>Reference ISO/IEC IS 14882:2003(E)</p>
45 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
46 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
47 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
48 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
49 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
52 <p>This document contains only library issues which have been closed
53 by the Library Working Group as duplicates or not defects. That is,
54 issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
55 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
56 information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
57 defects. The introductory material in that document also applies to
60 <h2>Revision History</h2>
62 <li>D73: Batavia meeting preview<ul>
63 <li><b>Summary:</b><ul>
64 <li>80 open issues, down by 126.</li>
65 <li>1459 closed issues, up by 145.</li>
66 <li>1539 issues total, up by 19.</li>
68 <li><b>Details:</b><ul>
69 <li>Added the following 11 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1521">1521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1523">1523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2008">2008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2012">2012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2013">2013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2014">2014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2015">2015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2016">2016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2017">2017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2018">2018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2019">2019</a>.</li>
70 <li>Added the following 5 Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2001">2001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2003">2003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2005">2005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2010">2010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2011">2011</a>.</li>
71 <li>Added the following Resolved issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2002">2002</a>.</li>
72 <li>Added the following Review issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2009">2009</a>.</li>
73 <li>Added the following Tentatively NAD issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2006">2006</a>.</li>
74 <li>Added the following 3 Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2000">2000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2004">2004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2007">2007</a>.</li>
75 <li>Added the following WP issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1522">1522</a>.</li>
76 <li>Changed the following 3 issues from New to Deferred: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1330">1330</a>.</li>
77 <li>Changed the following issue from Open to Deferred: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1450">1450</a>.</li>
78 <li>Changed the following 14 issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1350">1350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1375">1375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1443">1443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1451">1451</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1458">1458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1470">1470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1475">1475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1476">1476</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1477">1477</a>.</li>
79 <li>Changed the following issue from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1331">1331</a>.</li>
80 <li>Changed the following 8 issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1359">1359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1361">1361</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1373">1373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1376">1376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1398">1398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1446">1446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1473">1473</a>.</li>
81 <li>Changed the following 2 issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>.</li>
82 <li>Changed the following issue from WP to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>.</li>
83 <li>Changed the following 11 issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1395">1395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1442">1442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1471">1471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1472">1472</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1489">1489</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1495">1495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1496">1496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1509">1509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1510">1510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1511">1511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1512">1512</a>.</li>
84 <li>Changed the following issue from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>.</li>
85 <li>Changed the following issue from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1289">1289</a>.</li>
86 <li>Changed the following 6 issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1406">1406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1422">1422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1484">1484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1488">1488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1493">1493</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1499">1499</a>.</li>
87 <li>Changed the following 2 issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>.</li>
88 <li>Changed the following 2 issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1297">1297</a>.</li>
89 <li>Changed the following 3 issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1318">1318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1332">1332</a>.</li>
90 <li>Changed the following 6 issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385">1385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1401">1401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1408">1408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1418">1418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1420">1420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1438">1438</a>.</li>
91 <li>Changed the following 42 issues from NAD Editorial to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1321">1321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1394">1394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1405">1405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1407">1407</a>.</li>
92 <li>Changed the following 5 issues from New to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1322">1322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1326">1326</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1328">1328</a>.</li>
93 <li>Changed the following 46 issues from Open to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1327">1327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1344">1344</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1346">1346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1347">1347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1355">1355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1356">1356</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1357">1357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1377">1377</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1378">1378</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1379">1379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1380">1380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1382">1382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1383">1383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1389">1389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1390">1390</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1391">1391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1392">1392</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1393">1393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1397">1397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1409">1409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1410">1410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1412">1412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1445">1445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1447">1447</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1453">1453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1455">1455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1462">1462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1464">1464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1465">1465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1466">1466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1468">1468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1481">1481</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1482">1482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1490">1490</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1491">1491</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1492">1492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1498">1498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1501">1501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1508">1508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1513">1513</a>.</li>
94 <li>Changed the following issue from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1480">1480</a>.</li>
95 <li>Changed the following 2 issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1371">1371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1413">1413</a>.</li>
96 <li>Changed the following issue from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1320">1320</a>.</li>
97 <li>Changed the following 3 issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1310">1310</a>.</li>
98 <li>Changed the following issue from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1497">1497</a>.</li>
99 <li>Changed the following 24 issues from NAD Editorial to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1360">1360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1363">1363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1367">1367</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1372">1372</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1381">1381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1384">1384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1386">1386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1387">1387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1388">1388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1399">1399</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1400">1400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1402">1402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1403">1403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1416">1416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1417">1417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1423">1423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1424">1424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1425">1425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1426">1426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1427">1427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1429">1429</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1430">1430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1431">1431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1441">1441</a>.</li>
100 <li>Changed the following issue from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1294">1294</a>.</li>
101 <li>Changed the following 10 issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1354">1354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1362">1362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1368">1368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1370">1370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1428">1428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1435">1435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1436">1436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1437">1437</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1439">1439</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1440">1440</a>.</li>
102 <li>Changed the following 2 issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.</li>
103 <li>Changed the following 33 issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1404">1404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1414">1414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1432">1432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1449">1449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1516">1516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1517">1517</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1518">1518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1519">1519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1520">1520</a>.</li>
108 2010-10-18 pre-Batavia mailing.
110 <li><b>Summary:</b><ul>
111 <li>206 open issues, up by 141.</li>
112 <li>1314 closed issues, up by 36.</li>
113 <li>1520 issues total, up by 177.</li>
115 <li><b>Details:</b><ul>
116 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1433">1433</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1444">1444</a>.</li>
117 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1360">1360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1363">1363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1367">1367</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1372">1372</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1381">1381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1384">1384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1386">1386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1387">1387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1388">1388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1394">1394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1399">1399</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1400">1400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1402">1402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1403">1403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1405">1405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1407">1407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1415">1415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1416">1416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1417">1417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1419">1419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1423">1423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1424">1424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1425">1425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1426">1426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1427">1427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1429">1429</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1430">1430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1431">1431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1434">1434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1441">1441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1483">1483</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1500">1500</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1506">1506</a>.</li>
118 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1344">1344</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1345">1345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1346">1346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1347">1347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1348">1348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1349">1349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1350">1350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1353">1353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1354">1354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1355">1355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1356">1356</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1357">1357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1358">1358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1359">1359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1361">1361</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1362">1362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1364">1364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1368">1368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1369">1369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1370">1370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1371">1371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1373">1373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1374">1374</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1375">1375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1376">1376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1377">1377</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1378">1378</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1379">1379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1380">1380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1382">1382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1383">1383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385">1385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1389">1389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1390">1390</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1391">1391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1392">1392</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1393">1393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1395">1395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1396">1396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1397">1397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1398">1398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1401">1401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1406">1406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1408">1408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1409">1409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1410">1410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1412">1412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1413">1413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1418">1418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1420">1420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1421">1421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1422">1422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1428">1428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1435">1435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1436">1436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1437">1437</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1438">1438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1439">1439</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1440">1440</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1442">1442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1443">1443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1445">1445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1446">1446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1447">1447</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1448">1448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1450">1450</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1451">1451</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1452">1452</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1453">1453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1455">1455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1456">1456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1457">1457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1458">1458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1459">1459</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1460">1460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1461">1461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1462">1462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1464">1464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1465">1465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1466">1466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1468">1468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1470">1470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1471">1471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1472">1472</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1473">1473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1475">1475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1476">1476</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1477">1477</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1478">1478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1479">1479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1480">1480</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1481">1481</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1482">1482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1484">1484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1485">1485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1486">1486</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1487">1487</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1488">1488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1489">1489</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1490">1490</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1491">1491</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1492">1492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1493">1493</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1494">1494</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1495">1495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1496">1496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1497">1497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1498">1498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1499">1499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1501">1501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1502">1502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1503">1503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1504">1504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1505">1505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1507">1507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1508">1508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1509">1509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1510">1510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1511">1511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1512">1512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1513">1513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1514">1514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1515">1515</a>.</li>
119 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1404">1404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1414">1414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1432">1432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1449">1449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1516">1516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1517">1517</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1518">1518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1519">1519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1520">1520</a>.</li>
120 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>.</li>
121 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>.</li>
122 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>.</li>
127 2010-08-25 post-Rapperswil mailing.
129 <li><b>Summary:</b><ul>
130 <li>65 open issues, up by 2.</li>
131 <li>1278 closed issues, up by 7.</li>
132 <li>1343 issues total, up by 9.</li>
134 <li><b>Details:</b><ul>
135 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2008">2008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2009">2009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2010">2010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2011">2011</a>.</li>
136 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>.</li>
137 <li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>.</li>
138 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>.</li>
139 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>.</li>
140 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.</li>
141 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>.</li>
142 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>.</li>
143 <li>Changed the following issues from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>.</li>
144 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>.</li>
145 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>.</li>
146 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>.</li>
147 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>.</li>
152 2010-03-26 post-Pittsburgh mailing.
154 <li><b>Summary:</b><ul>
155 <li>63 open issues, down by 203.</li>
156 <li>1271 closed issues, up by 219.</li>
157 <li>1334 issues total, up by 16.</li>
159 <li><b>Details:</b><ul>
160 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1321">1321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1329">1329</a>.</li>
161 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1320">1320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1322">1322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1326">1326</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1328">1328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1330">1330</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1331">1331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1332">1332</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>.</li>
162 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1327">1327</a>.</li>
163 <li>Changed the following issues from Tentatively Dup to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>.</li>
164 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1302">1302</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1308">1308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1313">1313</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1314">1314</a>.</li>
165 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1228">1228</a>.</li>
166 <li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1263">1263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1265">1265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1296">1296</a>.</li>
167 <li>Changed the following issues from Tentatively NAD Concepts to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
168 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1266">1266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1269">1269</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1272">1272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1275">1275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1291">1291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1305">1305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1311">1311</a>.</li>
169 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#446">446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
170 <li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>.</li>
171 <li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1239">1239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1301">1301</a>.</li>
172 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1273">1273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1274">1274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1300">1300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1304">1304</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1315">1315</a>.</li>
173 <li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1317">1317</a>.</li>
174 <li>Changed the following issues from Ready to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>.</li>
175 <li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1238">1238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1282">1282</a>.</li>
176 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>.</li>
177 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>.</li>
178 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>.</li>
179 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>.</li>
180 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>.</li>
181 <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a>.</li>
182 <li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#427">427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#896">896</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>.</li>
183 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.</li>
184 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1241">1241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1261">1261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1262">1262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1264">1264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1267">1267</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1271">1271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1276">1276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1277">1277</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1280">1280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1284">1284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1285">1285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1286">1286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1298">1298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1299">1299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1303">1303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1306">1306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1312">1312</a>.</li>
189 2010-02-12 pre-Pittsburgh mailing.
191 <li><b>Summary:</b><ul>
192 <li>266 open issues, up by 61.</li>
193 <li>1052 closed issues, down by 3.</li>
194 <li>1318 issues total, up by 58.</li>
196 <li><b>Details:</b><ul>
197 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1266">1266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1269">1269</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1272">1272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1275">1275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1289">1289</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1291">1291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1294">1294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1297">1297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1302">1302</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1305">1305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1308">1308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1310">1310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1311">1311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1313">1313</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1314">1314</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1317">1317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1318">1318</a>.</li>
198 <li>Added the following Tentatively NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1263">1263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1265">1265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1296">1296</a>.</li>
199 <li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1301">1301</a>.</li>
200 <li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1282">1282</a>.</li>
201 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1261">1261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1262">1262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1264">1264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1267">1267</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1271">1271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1273">1273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1274">1274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1276">1276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1277">1277</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1280">1280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1284">1284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1285">1285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1286">1286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1298">1298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1299">1299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1300">1300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1303">1303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1304">1304</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1306">1306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1312">1312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1315">1315</a>.</li>
202 <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#101">101</a>.</li>
203 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
204 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>.</li>
205 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>.</li>
206 <li>Changed the following issues from New to Tentatively Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>.</li>
207 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>.</li>
208 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>.</li>
209 <li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>.</li>
210 <li>Changed the following issues from Open to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>.</li>
211 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>.</li>
212 <li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>.</li>
213 <li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>.</li>
214 <li>Changed the following issues from NAD to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>.</li>
215 <li>Changed the following issues from NAD Editorial to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>.</li>
216 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>.</li>
217 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>.</li>
218 <li>Changed the following issues from Ready to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.</li>
219 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>.</li>
220 <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
225 2009-11-06 post-Santa Cruz mailing.
227 <li><b>Summary:</b><ul>
228 <li>205 open issues, down by 77.</li>
229 <li>1055 closed issues, up by 120.</li>
230 <li>1260 issues total, up by 43.</li>
232 <li><b>Details:</b><ul>
233 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a>.</li>
234 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1236">1236</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1243">1243</a>.</li>
235 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a>.</li>
236 <li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1235">1235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1242">1242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
237 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>.</li>
238 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1228">1228</a>.</li>
239 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.</li>
240 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>.</li>
241 <li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1239">1239</a>.</li>
242 <li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1238">1238</a>.</li>
243 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1241">1241</a>.</li>
244 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>.</li>
245 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>.</li>
246 <li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>.</li>
247 <li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
248 <li>Changed the following issues from Tentatively NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
249 <li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
250 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.</li>
251 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
252 <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>.</li>
253 <li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
254 <li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>.</li>
255 <li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>.</li>
256 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>.</li>
257 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>.</li>
258 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>.</li>
259 <li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
260 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>.</li>
261 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>.</li>
262 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>.</li>
263 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>.</li>
264 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>.</li>
265 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>.</li>
266 <li>Changed the following issues from New to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
267 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>.</li>
268 <li>Changed the following issues from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>.</li>
269 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>.</li>
270 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>.</li>
271 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</li>
272 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
273 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
278 2009-09-25 pre-Santa Cruz mailing.
280 <li><b>Summary:</b><ul>
281 <li>282 open issues, up by 32.</li>
282 <li>935 closed issues, down by 1.</li>
283 <li>1217 issues total, up by 31.</li>
285 <li><b>Details:</b><ul>
286 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
287 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>.</li>
288 <li>Changed the following issues from WP to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
289 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>.</li>
290 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>.</li>
295 2009-07-31 post-Frankfurt mailing.
297 <li><b>Summary:</b><ul>
298 <li>250 open issues, down by 128.</li>
299 <li>936 closed issues, up by 171.</li>
300 <li>1186 issues total, up by 43.</li>
302 <li><b>Details:</b><ul>
303 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
304 <li>Added the following NAD Concepts issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1149">1149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1167">1167</a>.</li>
305 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1168">1168</a>.</li>
306 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
307 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
308 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
309 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>.</li>
310 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>.</li>
311 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#290">290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#394">394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#398">398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#417">417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>.</li>
312 <li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>.</li>
313 <li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>.</li>
314 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>.</li>
315 <li>Changed the following issues from New to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
316 <li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>.</li>
317 <li>Changed the following issues from Review to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
318 <li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
319 <li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
320 <li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>.</li>
321 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>.</li>
322 <li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>.</li>
323 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
324 <li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
325 <li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
326 <li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>.</li>
327 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>.</li>
328 <li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>.</li>
329 <li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
330 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>.</li>
331 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>.</li>
332 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>.</li>
333 <li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>.</li>
334 <li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>.</li>
335 <li>Changed the following issues from NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>.</li>
336 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>.</li>
337 <li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.</li>
338 <li>Changed the following issues from Tentatively Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>.</li>
339 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
340 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
341 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
342 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>.</li>
347 2009-06-19 pre-Frankfurt mailing.
349 <li><b>Summary:</b><ul>
350 <li>378 open issues, up by 32.</li>
351 <li>765 closed issues, up by 0.</li>
352 <li>1143 issues total, up by 32.</li>
354 <li><b>Details:</b><ul>
355 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
356 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</li>
357 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
358 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>.</li>
359 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
360 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
361 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>.</li>
362 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
363 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
364 <li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>.</li>
365 <li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
366 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
367 <li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>.</li>
368 <li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.</li>
369 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
370 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
371 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>.</li>
372 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
377 2009-05-01 mid-term mailing.
379 <li><b>Summary:</b><ul>
380 <li>346 open issues, up by 19.</li>
381 <li>765 closed issues, up by 0.</li>
382 <li>1111 issues total, up by 19.</li>
384 <li><b>Details:</b><ul>
385 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
386 <li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
387 <li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
392 2009-03-20 post-Summit mailing.
394 <li><b>Summary:</b><ul>
395 <li>327 open issues, up by 96.</li>
396 <li>765 closed issues, up by 14.</li>
397 <li>1092 issues total, up by 110.</li>
399 <li><b>Details:</b><ul>
400 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
401 <li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
402 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
403 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>.</li>
404 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
405 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
406 <li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
407 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
408 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</li>
409 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.</li>
410 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
411 <li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
412 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>.</li>
413 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
414 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>.</li>
415 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>.</li>
416 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
417 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
418 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.</li>
419 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>.</li>
420 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>.</li>
421 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
422 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
427 2009-02-06 pre-Summit mailing.
429 <li><b>Summary:</b><ul>
430 <li>231 open issues, up by 44.</li>
431 <li>751 closed issues, up by 0.</li>
432 <li>982 issues total, up by 44.</li>
434 <li><b>Details:</b><ul>
435 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
440 2008-12-05 mid-term mailing.
442 <li><b>Summary:</b><ul>
443 <li>187 open issues, up by 20.</li>
444 <li>751 closed issues, up by 0.</li>
445 <li>938 issues total, up by 20.</li>
447 <li><b>Details:</b><ul>
448 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>.</li>
453 2008-10-03 post-San Francisco mailing.
455 <li><b>Summary:</b><ul>
456 <li>167 open issues, down by 25.</li>
457 <li>751 closed issues, up by 65.</li>
458 <li>918 issues total, up by 40.</li>
460 <li><b>Details:</b><ul>
461 <li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
462 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
463 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#896">896</a>.</li>
464 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
465 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
466 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
467 <li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
468 <li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
469 <li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
470 <li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
471 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
472 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>.</li>
473 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
474 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>.</li>
475 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>.</li>
476 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
477 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
478 <li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
479 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
480 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
481 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
482 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
483 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
484 <li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
489 2008-08-22 pre-San Francisco mailing.
491 <li><b>Summary:</b><ul>
492 <li>192 open issues, up by 9.</li>
493 <li>686 closed issues, up by 0.</li>
494 <li>878 issues total, up by 9.</li>
496 <li><b>Details:</b><ul>
497 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
502 2008-07-28 mid-term mailing.
504 <li><b>Summary:</b><ul>
505 <li>183 open issues, up by 12.</li>
506 <li>686 closed issues, down by 4.</li>
507 <li>869 issues total, up by 8.</li>
509 <li><b>Details:</b><ul>
510 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>.</li>
511 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
512 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
513 <li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
514 <li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
519 2008-06-27 post-Sophia Antipolis mailing.
521 <li><b>Summary:</b><ul>
522 <li>171 open issues, down by 20.</li>
523 <li>690 closed issues, up by 43.</li>
524 <li>861 issues total, up by 23.</li>
526 <li><b>Details:</b><ul>
527 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
528 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>.</li>
529 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
530 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
531 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
532 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
533 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
534 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
535 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
536 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>.</li>
537 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>.</li>
538 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.</li>
539 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
540 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
541 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
542 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
543 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
544 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
545 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
550 2008-05-16 pre-Sophia Antipolis mailing.
552 <li><b>Summary:</b><ul>
553 <li>191 open issues, up by 24.</li>
554 <li>647 closed issues, up by 1.</li>
555 <li>838 issues total, up by 25.</li>
557 <li><b>Details:</b><ul>
558 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>.</li>
559 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
564 2008-03-14 post-Bellevue mailing.
566 <li><b>Summary:</b><ul>
567 <li>167 open issues, down by 39.</li>
568 <li>646 closed issues, up by 65.</li>
569 <li>813 issues total, up by 26.</li>
571 <li><b>Details:</b><ul>
572 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
573 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
574 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
575 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
576 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
577 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
578 <li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li>
579 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
580 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
581 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
582 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
583 <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
584 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>.</li>
585 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>.</li>
586 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>.</li>
587 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
588 <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
589 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
590 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
591 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
592 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
593 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>.</li>
594 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
595 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
600 2008-02-01 pre-Bellevue mailing.
602 <li><b>Summary:</b><ul>
603 <li>206 open issues, up by 23.</li>
604 <li>581 closed issues, up by 0.</li>
605 <li>787 issues total, up by 23.</li>
607 <li><b>Details:</b><ul>
608 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>.</li>
609 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
610 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>.</li>
611 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>.</li>
612 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
613 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
618 2007-12-09 mid-term mailing.
620 <li><b>Summary:</b><ul>
621 <li>183 open issues, up by 11.</li>
622 <li>581 closed issues, down by 1.</li>
623 <li>764 issues total, up by 10.</li>
625 <li><b>Details:</b><ul>
626 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
627 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.</li>
628 <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
633 2007-10-19 post-Kona mailing.
635 <li><b>Summary:</b><ul>
636 <li>172 open issues, up by 4.</li>
637 <li>582 closed issues, up by 27.</li>
638 <li>754 issues total, up by 31.</li>
640 <li><b>Details:</b><ul>
641 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
642 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
643 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
644 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
645 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
646 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
647 <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
648 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
649 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
650 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>.</li>
651 <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
652 <li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
653 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
658 2007-09-09 pre-Kona mailing.
660 <li><b>Summary:</b><ul>
661 <li>168 open issues, up by 15.</li>
662 <li>555 closed issues, up by 0.</li>
663 <li>723 issues total, up by 15.</li>
665 <li><b>Details:</b><ul>
666 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>.</li>
671 2007-08-05 post-Toronto mailing.
673 <li><b>Summary:</b><ul>
674 <li>153 open issues, down by 5.</li>
675 <li>555 closed issues, up by 17.</li>
676 <li>708 issues total, up by 12.</li>
678 <li><b>Details:</b><ul>
679 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
680 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
681 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
682 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
683 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>.</li>
684 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
685 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
686 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
687 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
688 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
689 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
690 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
691 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
692 <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
693 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
698 2007-06-23 pre-Toronto mailing.
700 <li><b>Summary:</b><ul>
701 <li>158 open issues, up by 13.</li>
702 <li>538 closed issues, up by 7.</li>
703 <li>696 issues total, up by 20.</li>
705 <li><b>Details:</b><ul>
706 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>.</li>
707 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
708 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
709 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
710 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
715 2007-05-06 post-Oxford mailing.
717 <li><b>Summary:</b><ul>
718 <li>145 open issues, down by 33.</li>
719 <li>531 closed issues, up by 53.</li>
720 <li>676 issues total, up by 20.</li>
722 <li><b>Details:</b><ul>
723 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>.</li>
724 <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
725 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
726 <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
727 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
728 <li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
729 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>.</li>
730 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
731 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.</li>
732 <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
733 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
734 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
735 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
736 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
737 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
742 2007-03-09 pre-Oxford mailing.
744 <li><b>Summary:</b><ul>
745 <li>178 open issues, up by 37.</li>
746 <li>478 closed issues, up by 0.</li>
747 <li>656 issues total, up by 37.</li>
749 <li><b>Details:</b><ul>
750 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
751 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
752 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>.</li>
753 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
754 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
755 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
760 2007-01-12 mid-term mailing.
762 <li><b>Summary:</b><ul>
763 <li>141 open issues, up by 11.</li>
764 <li>478 closed issues, down by 1.</li>
765 <li>619 issues total, up by 10.</li>
767 <li><b>Details:</b><ul>
768 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
773 2006-11-03 post-Portland mailing.
775 <li><b>Summary:</b><ul>
776 <li>130 open issues, up by 0.</li>
777 <li>479 closed issues, up by 17.</li>
778 <li>609 issues total, up by 17.</li>
780 <li><b>Details:</b><ul>
781 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
782 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
783 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
784 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a> to Open.</li>
785 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
786 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
787 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
792 2006-09-08 pre-Portland mailing.
794 <li><b>Summary:</b><ul>
795 <li>130 open issues, up by 6.</li>
796 <li>462 closed issues, down by 1.</li>
797 <li>592 issues total, up by 5.</li>
799 <li><b>Details:</b><ul>
800 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
805 2006-06-23 mid-term mailing.
807 <li><b>Summary:</b><ul>
808 <li>124 open issues, up by 14.</li>
809 <li>463 closed issues, down by 1.</li>
810 <li>587 issues total, up by 13.</li>
812 <li><b>Details:</b><ul>
813 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>.</li>
814 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
815 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
820 2006-04-21 post-Berlin mailing.
822 <li><b>Summary:</b><ul>
823 <li>110 open issues, down by 16.</li>
824 <li>464 closed issues, up by 24.</li>
825 <li>574 issues total, up by 8.</li>
827 <li><b>Details:</b><ul>
828 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
829 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
830 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
831 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
832 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
833 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
838 2006-02-24 pre-Berlin mailing.
840 <li><b>Summary:</b><ul>
841 <li>126 open issues, up by 31.</li>
842 <li>440 closed issues, up by 0.</li>
843 <li>566 issues total, up by 31.</li>
845 <li><b>Details:</b><ul>
846 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
847 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
848 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
853 2005-12-16 mid-term mailing.
855 <li><b>Summary:</b><ul>
856 <li>95 open issues.</li>
857 <li>440 closed issues.</li>
858 <li>535 issues total.</li>
860 <li><b>Details:</b><ul>
861 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
866 2005-10-14 post-Mont Tremblant mailing.
867 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
868 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
869 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
870 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
871 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
872 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
873 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
876 2005-07-03 pre-Mont Tremblant mailing.
877 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
878 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>
881 2005-06 mid-term mailing.
882 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
885 2005-04 post-Lillehammer mailing. All issues in "ready" status except
886 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
887 previously in "DR" status were moved to "WP".
890 2005-03 pre-Lillehammer mailing.
893 2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
896 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
899 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
900 new issues received after the 2004-07 mailing. Added
901 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
904 2004-07 mid-term mailing: reflects new proposed resolutions and
905 new issues received after the post-Sydney mailing. Added
906 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
909 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
910 Voted all "Ready" issues from R29 into the working paper.
911 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
914 Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
917 Post-Kona mailing: reflects decisions made at the Kona meeting.
918 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
921 Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>.
924 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
925 All issues in Ready status were voted into DR status. All issues in
926 DR status were voted into WP status.
929 Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
932 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
933 meeting. All Ready issues from R23 with the exception of <iref ref="253">, which has been given a new proposed resolution, were
934 moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<iref ref="389">. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
935 at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <iref ref="226">, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <iref ref="229"> have been moved to Ready status, and the only remaining
936 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
937 </iref></iref></iref></iref></li>
939 Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>.
940 Moved issues in the TC to TC status.
943 Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<iref ref="366">.
946 Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<iref ref="361">.
949 Post-Redmond mailing; reflects actions taken in Redmond. Added
950 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
951 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
952 not discussed at the meeting.
954 All Ready issues were moved to DR status, with the exception of issues
955 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
957 Noteworthy issues discussed at Redmond include
958 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>,
959 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
962 Pre-Redmond mailing. Added new issues
963 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
966 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
967 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
968 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
970 Changed status of issues
971 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
972 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
973 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
974 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
975 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
976 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
977 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
980 Changed status of issues
981 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
982 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
983 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
984 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
985 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
986 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
987 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
988 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
989 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
993 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
994 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
1000 Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
1001 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <iref ref="91">, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
1002 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
1005 post-Toronto mailing; reflects actions taken in Toronto. Added new
1006 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
1007 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
1008 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
1009 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
1010 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
1011 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
1012 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
1013 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
1014 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
1015 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
1016 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
1017 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
1018 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
1019 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>. Reopened
1020 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
1021 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
1022 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
1023 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
1024 the bug in enough places.
1027 pre-Toronto mailing. Added issues
1028 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
1029 changes so that we pass Weblint tests.
1032 post-Tokyo II mailing; reflects committee actions taken in
1033 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
1036 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
1039 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
1040 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
1041 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
1042 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
1045 post-Kona mailing: Updated to reflect LWG and full committee actions
1046 in Kona (99-0048/N1224). Note changed resolution of issues
1047 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
1048 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
1049 "closed" documents. Changed the proposed resolution of issue
1050 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
1051 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
1054 pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
1055 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
1056 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
1057 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
1060 pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
1061 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
1062 "closed" documents. (99-0030/N1206, 25 Aug 99)
1065 post-Dublin mailing. Updated to reflect LWG and full committee actions
1066 in Dublin. (99-0016/N1193, 21 Apr 99)
1069 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
1070 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
1071 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
1072 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
1075 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
1076 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
1079 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
1080 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
1081 for making list public. (30 Dec 98)
1084 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
1085 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
1086 issues corrected. (22 Oct 98)
1089 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
1090 added, many issues updated to reflect LWG consensus (12 Oct 98)
1093 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
1094 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
1097 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
1098 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
1102 <h2>Closed Issues</h2>
1104 <h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
1105 <p><b>Section:</b> D.12.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1106 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1997-12-04 <b>Last modified:</b> 2010-10-29</p>
1107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1108 <p><b>Discussion:</b></p>
1109 <p>Paragraph 1 in "Effects", says "Calls
1110 p->release()" where it clearly must be "Calls
1111 p.release()". (As it is, it seems to require using
1112 auto_ptr<>::operator-> to refer to X::release, assuming that
1116 <p><b>Proposed resolution:</b></p>
1117 <p>Change 20.7.4.3 [meta.unary.prop] paragraph 1 Effects from
1118 "Calls p->release()" to "Calls p.release()".</p>
1121 <p><b>Rationale:</b></p>
1122 <p>Not a defect: the proposed change is already found in the standard.
1123 [Originally classified as a defect, later reclassified.]</p>
1130 <h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
1131 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1132 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <b>Last modified:</b> 2010-10-29</p>
1133 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
1134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1135 <p><b>Discussion:</b></p>
1136 <p>In Morristown we changed the size_type and difference_type typedefs
1137 for all the other containers to implementation defined with a
1138 reference to 23.2 [container.requirements]. This should probably also have been
1139 done for strings. </p>
1142 <p><b>Rationale:</b></p>
1143 <p>Not a defect. [Originally classified as a defect, later
1144 reclassified.] basic_string, unlike the other standard library
1145 template containers, is severely constrained by its use of
1146 char_traits. Those types are dictated by the traits class, and are far
1147 from implementation defined.</p>
1154 <h3><a name="6"></a>6. File position not an offset unimplementable</h3>
1155 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1156 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2010-10-29</p>
1157 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
1158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1159 <p><b>Discussion:</b></p>
1160 <p>Table 88, in I/O, is too strict; it's unimplementable on systems
1161 where a file position isn't just an offset. It also never says just
1162 what fpos<> is really supposed to be. [Here's my summary, which
1163 Jerry agrees is more or less accurate. "I think I now know what
1164 the class really is, at this point: it's a magic cookie that
1165 encapsulates an mbstate_t and a file position (possibly represented as
1166 an fpos_t), it has syntactic support for pointer-like arithmetic, and
1167 implementors are required to have real, not just syntactic, support
1168 for arithmetic." This isn't standardese, of course.] </p>
1171 <p><b>Rationale:</b></p>
1172 <p>Not a defect. The LWG believes that the Standard is already clear,
1173 and that the above summary is what the Standard in effect says.</p>
1180 <h3><a name="10"></a>10. Codecvt<>::do unclear</h3>
1181 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1182 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-14 <b>Last modified:</b> 2010-10-29</p>
1183 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
1184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1185 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
1186 <p><b>Discussion:</b></p>
1187 <p>Section 22.2.1.5.2 says that codecvt<>::do_in and do_out
1188 should return the value noconv if "no conversion was
1189 needed". However, I don't see anything anywhere that defines what
1190 it means for a conversion to be needed or not needed. I can think of
1191 several circumstances where one might plausibly think that a
1192 conversion is not "needed", but I don't know which one is
1196 <p><b>Rationale:</b></p>
1204 <h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
1205 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1206 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-02-23 <b>Last modified:</b> 2010-10-29</p>
1207 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
1208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1209 <p><b>Discussion:</b></p>
1210 <p>I couldn't find a statement in the standard saying whether the allocator object held by
1211 a container is held as a copy of the constructor argument or whether a pointer of
1212 reference is maintained internal. There is an according statement for compare objects and
1213 how they are maintained by the associative containers, but I couldn't find anything
1214 regarding allocators. </p>
1216 <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
1220 <p><b>Rationale:</b></p>
1221 <p>Not a defect. The LWG believes that the Standard is already
1222 clear. See 23.2 [container.requirements], paragraph 8.</p>
1229 <h3><a name="43"></a>43. Locale table correction</h3>
1230 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1231 <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2010-10-29</p>
1232 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
1233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1234 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
1235 <p><b>Discussion:</b></p>
1238 <p><b>Rationale:</b></p>
1246 <h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
1247 <p><b>Section:</b> 27.8.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1248 <b>Submitter:</b> Matthias Mueller <b>Opened:</b> 1998-05-27 <b>Last modified:</b> 2010-10-29</p>
1249 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1250 <p><b>Discussion:</b></p>
1251 <p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
1253 <p>"We are not sure how to interpret the CD2 (see 27.3 [iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1 [stringbuf.cons])
1254 with respect to the question as to what the correct initial positions
1255 of the write and read pointers of a stringstream should
1258 <p>"Is it the same to output two strings or to initialize the stringstream with the
1259 first and to output the second?"</p>
1261 <p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
1262 Jerry Schwarz have all offered opinions; see reflector messages
1263 lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
1268 <p><b>Rationale:</b></p>
1269 <p>The LWG believes the Standard is correct as written. The behavior
1270 of stringstreams is consistent with fstreams, and there is a
1271 constructor which can be used to obtain the desired effect. This
1272 behavior is known to be different from strstreams.</p>
1279 <h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
1280 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1281 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2010-10-29</p>
1282 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
1283 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1284 <p><b>Discussion:</b></p>
1285 <p>27.6.1.2.3 has member functions for extraction of signed char and
1286 unsigned char, both singly and as strings. However, it doesn't say
1287 what it means to extract a <tt>char</tt> from a
1288 <tt>basic_streambuf<charT, Traits></tt>. </p>
1290 <p>basic_streambuf, after all, has no members to extract a char, so
1291 basic_istream must somehow convert from charT to signed char or
1292 unsigned char. The standard doesn't say how it is to perform that
1296 <p><b>Rationale:</b></p>
1297 <p>The Standard is correct as written. There is no such extractor and
1298 this is the intent of the LWG.</p>
1304 <h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
1305 <p><b>Section:</b> D.9.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1306 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2010-10-29</p>
1307 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
1308 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1309 <p><b>Discussion:</b></p>
1310 <p>The standard says how this member function affects the current
1311 stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
1312 say how this member function affects the beginning and end of the
1315 <p>This is an issue when seekoff is used to position the get pointer
1316 beyond the end of the current read area. (Which is legal. This is
1317 implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
1321 <p><b>Rationale:</b></p>
1322 <p>The LWG agrees that seekoff() is underspecified, but does not wish
1323 to invest effort in this deprecated feature.</p>
1330 <h3><a name="67"></a>67. Setw useless for strings</h3>
1331 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1332 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-07-09 <b>Last modified:</b> 2010-10-29</p>
1333 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
1334 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1335 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
1336 <p><b>Discussion:</b></p>
1337 <p>In a comp.std.c++ posting Michel Michaud wrote: What
1338 should be output by: </p>
1340 <pre> string text("Hello");
1341 cout << '[' << setw(10) << right << text << ']';
1344 <p>Shouldn't it be:</p>
1346 <pre> [ Hello]</pre>
1348 <p>Another person replied: Actually, according to the FDIS, the width
1349 of the field should be the minimum of width and the length of the
1350 string, so the output shouldn't have any padding. I think that this is
1351 a typo, however, and that what is wanted is the maximum of the
1352 two. (As written, setw is useless for strings. If that had been the
1353 intent, one wouldn't expect them to have mentioned using its value.)
1356 <p>It's worth pointing out that this is a recent correction anyway;
1357 IIRC, earlier versions of the draft forgot to mention formatting
1358 parameters whatsoever.</p>
1361 <p><b>Rationale:</b></p>
1369 <h3><a name="72"></a>72. Do_convert phantom member function</h3>
1370 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1371 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-24 <b>Last modified:</b> 2010-10-29</p>
1372 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1373 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1374 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
1375 <p><b>Discussion:</b></p>
1376 <p>In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
1377 "do_convert" is mentioned. This member was replaced with
1378 "do_in" and "do_out", the proper referents in the
1382 <p><b>Rationale:</b></p>
1389 <h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
1390 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1391 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-27 <b>Last modified:</b> 2010-10-29</p>
1392 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
1393 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1394 <p><b>Discussion:</b></p>
1395 <p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
1396 <tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
1397 should be a <tt>const</tt> member function, since it does nothing but
1398 call one of <tt>basic_filebuf</tt>'s const member functions. </p>
1401 <p><b>Rationale:</b></p>
1402 <p>Not a defect. This is a deliberate feature; const streams would be
1409 <h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
1410 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1411 <b>Submitter:</b> Levente Farkas <b>Opened:</b> 1998-09-09 <b>Last modified:</b> 2010-10-29</p>
1412 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
1413 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1414 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
1415 <p><b>Discussion:</b></p>
1418 <tt>T operator[] (size_t) const;</tt><br>
1422 <tt>const T& operator[] (size_t) const;</tt><br>
1424 as in vector ???<br>
1426 One can't copy even from a const valarray eg:<br>
1428 <tt>memcpy(ptr, &v[0], v.size() * sizeof(double));<br>
1430 [I] find this bug in valarray is very difficult.</p>
1433 <p><b>Rationale:</b></p>
1434 <p>The LWG believes that the interface was deliberately designed that
1435 way. That is what valarray was designed to do; that's where the
1436 "value array" name comes from. LWG members further comment
1437 that "we don't want valarray to be a full STL container."
1438 26.6.2.3 [valarray.access] specifies properties that indicate "an
1439 absence of aliasing" for non-constant arrays; this allows
1440 optimizations, including special hardware optimizations, that are not
1441 otherwise possible. </p>
1448 <h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
1449 <p><b>Section:</b> 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1450 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1451 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
1452 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1453 <p><b>Discussion:</b></p>
1454 <p>Isn't the definition of copy constructor and assignment operators wrong?
1455 Instead of</p>
1457 <pre> slice_array(const slice_array&);
1458 slice_array& operator=(const slice_array&);</pre>
1460 <p>IMHO they have to be</p>
1462 <pre> slice_array(const slice_array<T>&);
1463 slice_array& operator=(const slice_array<T>&);</pre>
1465 <p>Same for gslice_array. </p>
1468 <p><b>Rationale:</b></p>
1469 <p>Not a defect. The Standard is correct as written. </p>
1475 <h3><a name="82"></a>82. Missing constant for set elements</h3>
1476 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1477 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1478 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
1479 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
1480 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1481 <p><b>Discussion:</b></p>
1482 <p>Paragraph 5 specifies:</p>
1485 For set and multiset the value type is the same as the key type. For
1486 map and multimap it is equal to pair<const Key, T>.
1489 <p>Strictly speaking, this is not correct because for set and multiset
1490 the value type is the same as the <b>constant</b> key type.</p>
1493 <p><b>Rationale:</b></p>
1494 <p>Not a defect. The Standard is correct as written; it uses a
1495 different mechanism (const &) for <tt>set</tt> and
1496 <tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
1503 <h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
1504 <p><b>Section:</b> 21.4.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1505 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1506 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1507 <p><b>Discussion:</b></p>
1509 <pre> s.insert(0,1,' ');</pre>
1511 <p> I get an nasty ambiguity. It might be</p>
1512 <pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
1514 <p>which inserts 1 space character at position 0, or</p>
1515 <pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre>
1517 <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
1518 <pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
1520 <p>which normally inserts characters from iterator 1 to iterator '
1521 '. But according to 23.1.1.9 (the "do the right thing" fix)
1522 it is equivalent to the second. However, it is still ambiguous,
1523 because of course I mean the first!</p>
1526 <p><b>Rationale:</b></p>
1527 <p>Not a defect. The LWG believes this is a "genetic
1528 misfortune" inherent in the design of string and thus not a
1529 defect in the Standard as such .</p>
1535 <h3><a name="85"></a>85. String char types</h3>
1536 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1537 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1538 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
1539 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1540 <p><b>Discussion:</b></p>
1541 <p>The standard seems not to require that charT is equivalent to
1542 traits::char_type. So, what happens if charT is not equivalent to
1543 traits::char_type?</p>
1546 <p><b>Rationale:</b></p>
1547 <p>There is already wording in 21.2 [char.traits] paragraph 3 that
1548 requires them to be the same.</p>
1554 <h3><a name="87"></a>87. Error in description of string::compare()</h3>
1555 <p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1556 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1557 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
1558 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1559 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
1560 <p><b>Discussion:</b></p>
1561 <p>The following compare() description is obviously a bug:</p>
1563 <pre>int compare(size_type pos, size_type n1,
1564 charT *s, size_type n2 = npos) const;
1567 <p>because without passing n2 it should compare up to the end of the
1568 string instead of comparing npos characters (which throws an
1572 <p><b>Rationale:</b></p>
1579 <h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
1580 <p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1581 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1582 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
1583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1584 <p><b>Discussion:</b></p>
1586 <pre> template<class InputIterator>
1587 basic_string& append(InputIterator first, InputIterator last);</pre>
1589 <p>return a string, while</p>
1590 <pre> template<class InputIterator>
1591 void insert(iterator p, InputIterator first, InputIterator last);</pre>
1593 <p>returns nothing ?</p>
1596 <p><b>Rationale:</b></p>
1597 <p>The LWG believes this stylistic inconsistency is not sufficiently
1598 serious to constitute a defect.</p>
1604 <h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
1605 <p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1606 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
1608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1609 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
1610 <p><b>Discussion:</b></p>
1611 <p>All insert() and replace() members for strings with an iterator as
1612 first argument lack a throw specification. The throw
1613 specification should probably be: length_error if size exceeds
1617 <p><b>Rationale:</b></p>
1618 <p>Considered a duplicate because it will be solved by the resolution
1619 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
1626 <h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
1627 <p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1628 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
1629 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
1630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1631 <p><b>Discussion:</b></p>
1632 <p>You can easily create subsets, but you can't easily combine them
1633 with other subsets. Unfortunately, you almost always needs an
1634 explicit type conversion to valarray. This is because the standard
1635 does not specify that valarray subsets provide the same operations as
1638 <p>For example, to multiply two subsets and assign the result to a third subset, you can't
1639 write the following:</p>
1641 <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
1643 <p>Instead, you have to code as follows:</p>
1645 <pre>va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) *
1646 static_cast<valarray<double> >(va[slice(2,4,3)]);</pre>
1648 <p>This is tedious and error-prone. Even worse, it costs performance because each cast
1649 creates a temporary objects, which could be avoided without the cast. </p>
1652 <p><b>Proposed resolution:</b></p>
1653 <p>Extend all valarray subset types so that they offer all valarray operations.</p>
1656 <p><b>Rationale:</b></p>
1657 <p>This is not a defect in the Standard; it is a request for an extension.</p>
1663 <h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
1664 <p><b>Section:</b> 17.6.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1665 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2010-10-29</p>
1666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1667 <p><b>Discussion:</b></p>
1668 <p>Is it a permitted extension for library implementors to add template parameters to
1669 standard library classes, provided that those extra parameters have defaults? For example,
1670 instead of defining <tt>template <class T, class Alloc = allocator<T> > class
1671 vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>,
1672 int N = 1> class vector;</tt> </p>
1674 <p>The standard may well already allow this (I can't think of any way that this extension
1675 could break a conforming program, considering that users are not permitted to
1676 forward-declare standard library components), but it ought to be explicitly permitted or
1679 <p>comment from Steve Cleary via comp.std.c++:</p>
1681 <p>I disagree [with the proposed resolution] for the following reason:
1682 consider user library code with template template parameters. For
1683 example, a user library object may be templated on the type of
1684 underlying sequence storage to use (deque/list/vector), since these
1685 classes all take the same number and type of template parameters; this
1686 would allow the user to determine the performance tradeoffs of the
1687 user library object. A similar example is a user library object
1688 templated on the type of underlying set storage (set/multiset) or map
1689 storage (map/multimap), which would allow users to change (within
1690 reason) the semantic meanings of operations on that object.</p>
1691 <p>I think that additional template parameters should be forbidden in
1692 the Standard classes. Library writers don't lose any expressive power,
1693 and can still offer extensions because additional template parameters
1694 may be provided by a non-Standard implementation class:</p>
1696 template <class T, class Allocator = allocator<T>, int N = 1>
1699 template <class T, class Allocator = allocator<T> >
1700 class vector: public __vector<T, Allocator>
1708 <p><b>Proposed resolution:</b></p>
1709 <p>Add a new subclause [presumably 17.4.4.9] following 17.6.4.12 [res.on.exception.handling]:</p>
1712 <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
1713 template class described in the C++ Standard Library behaves the
1714 same as if the implementation declares no additional template
1715 parameters.</p> <p>Footnote: Additional template parameters with
1716 default values are thus permitted.</p>
1719 <p>Add "template parameters" to the list of subclauses at
1720 the end of 17.6.4 [conforming] paragraph 1.</p>
1722 <p><i>[Kona: The LWG agreed the standard needs clarification. After
1723 discussion with John Spicer, it seems added template parameters can be
1724 detected by a program using template-template parameters. A straw vote
1725 - "should implementors be allowed to add template
1726 parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
1731 <p><b>Rationale:</b></p>
1733 There is no ambiguity; the standard is clear as written. Library
1734 implementors are not permitted to add template parameters to standard
1735 library classes. This does not fall under the "as if" rule,
1736 so it would be permitted only if the standard gave explicit license
1737 for implementors to do this. This would require a change in the
1742 The LWG decided against making this change, because it would break
1743 user code involving template template parameters or specializations
1744 of standard library class templates.
1752 <h3><a name="95"></a>95. Members added by the implementation</h3>
1753 <p><b>Section:</b> 17.6.4.5 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1754 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
1755 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1756 <p><b>Discussion:</b></p>
1757 <p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
1758 members a base class and break user derived classes.</p>
1763 <pre>// implementation code:
1764 struct _Base { // _Base is in the implementer namespace
1765 virtual void foo ();
1767 class vector : _Base // deriving from a class is allowed
1771 class vector_checking : public vector
1773 void foo (); // don't want to override _Base::foo () as the
1774 // user doesn't know about _Base::foo ()
1779 <p><b>Proposed resolution:</b></p>
1780 <p>Clarify the wording to make the example illegal.</p>
1783 <p><b>Rationale:</b></p>
1784 <p>This is not a defect in the Standard. The example is already
1785 illegal. See 17.6.4.5 [member.functions] paragraph 2.</p>
1791 <h3><a name="96"></a>96. Vector<bool> is not a container</h3>
1792 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1793 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
1794 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
1795 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1796 <p><b>Discussion:</b></p>
1797 <p><tt>vector<bool></tt> is not a container as its reference and
1798 pointer types are not references and pointers. </p>
1800 <p>Also it forces everyone to have a space optimization instead of a
1803 <p><b>See also:</b> 99-0008 == N1185 Vector<bool> is
1804 Nonconforming, Forces Optimization Choice.</p>
1806 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
1809 <p><i>[In Dublin many present felt that failure to meet Container
1810 requirements was a defect. There was disagreement as to whether
1811 or not the optimization requirements constituted a defect.]</i></p>
1814 <p><i>[The LWG looked at the following resolutions in some detail:
1816 * Not A Defect.<br>
1817 * Add a note explaining that vector<bool> does not meet
1818 Container requirements.<br>
1819 * Remove vector<bool>.<br>
1820 * Add a new category of container requirements which
1821 vector<bool> would meet.<br>
1822 * Rename vector<bool>.<br>
1824 No alternative had strong, wide-spread, support and every alternative
1825 had at least one "over my dead body" response.<br>
1827 There was also mention of a transition scheme something like (1) add
1828 vector_bool and deprecate vector<bool> in the next standard. (2)
1829 Remove vector<bool> in the following standard.]</i></p>
1832 <p><i>[Modifying container requirements to permit returning proxies
1833 (thus allowing container requirements conforming vector<bool>)
1834 was also discussed.]</i></p>
1837 <p><i>[It was also noted that there is a partial but ugly workaround in
1838 that vector<bool> may be further specialized with a customer
1842 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1843 vector<bool>: More Problems, Better Solutions. Much discussion
1844 of a two step approach: a) deprecate, b) provide replacement under a
1845 new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
1846 my dead body. This resolution was mentioned in the LWG report to the
1847 full committee, where several additional committee members indicated
1848 over-my-dead-body positions.]</i></p>
1851 <p>Discussed at Lillehammer. General agreement that we should
1852 deprecate vector<bool> and introduce this functionality under
1853 a different name, e.g. bit_vector. This might make it possible to
1854 remove the vector<bool> specialization in the standard that comes
1855 after C++0x. There was also a suggestion that
1856 in C++0x we could additional say that it's implementation defined
1857 whether vector<bool> refers to the specialization or to the
1858 primary template, but there wasn't general agreement that this was a
1861 <p>We need a paper for the new bit_vector class.</p>
1868 The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1869 from <tt>vector<bool></tt>. Although some of the funcitonality from
1870 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1871 could well be used in such a template. The concern is easing the API migration for those
1872 users who want to continue using a bit-packed container. Alan and Beman to work.
1876 Post Summit Alisdair adds:
1882 <tt>vector<bool></tt> is now a conforming container under the revised terms of C++0x,
1883 which supports containers of proxies.
1892 i/ premature optimization in the specification.
1893 There is still some sentiment that deprecation is the correct way to go,
1894 although it is still not clear what it would mean to deprecate a single
1895 specialization of a template.
1898 Recommend: Create a new issue for the discussion, leave as Open.
1901 ii/ Request for a new bitvector class to guarantee the optimization, perhaps
1902 with a better tuned interface.
1905 This is a clear extension request that may be handled via a future TR.
1914 We note that most of this issue has become moot over time,
1915 and agree with Alisdair's recommendations.
1916 Move to NAD Future for reconsideration of part (ii).
1920 2009-07-29 Alisdair reopens:
1926 This infamous issue was closed as NAD Future when concepts introduced
1927 support for proxy iterators, so the only remaining requirement was to
1928 provide a better type to support bitsets of dynamic length. I fear we
1929 must re-open this issue until the post-concept form of iterators is
1930 available, and hopefully will support the necessary proxy functionality
1931 to allow us to close this issue as NAD.
1935 I recommend we spawn a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>) requesting a dynamic length bitset
1936 and pre-emptively file it as NAD Future. It is difficult to resolve #96
1937 when it effectively contains two separate sub-issues.
1947 Mark as NAD, and give rationale.
1952 <p><b>Proposed resolution:</b></p>
1955 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1957 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1962 <p><b>Rationale:</b></p>
1964 We want to support proxy iterators but that is going to be separate
1965 work. Don't want to see this issue come back in these kinds of terms.
1966 We're interested in a separate container, and proxy iterators, but both
1967 of those are separate issues.
1970 We've looked at a lot of ways to fix this that would be close to this,
1971 but those things would break existing code. Attempts to fix this
1972 directly have not been tractable, and removing it has not been
1973 tractable. Therefore we are closing.
1981 <h3><a name="97"></a>97. Insert inconsistent definition</h3>
1982 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1983 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
1984 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
1985 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1986 <p><b>Discussion:</b></p>
1987 <p><tt>insert(iterator, const value_type&)</tt> is defined both on
1988 sequences and on set, with unrelated semantics: insert here (in
1989 sequences), and insert with hint (in associative containers). They
1990 should have different names (B.S. says: do not abuse overloading).</p>
1993 <p><b>Rationale:</b></p>
1994 <p>This is not a defect in the Standard. It is a genetic misfortune of
1995 the design, for better or for worse.</p>
2001 <h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
2002 <p><b>Section:</b> 24.5.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2003 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2005 <p><b>Discussion:</b></p>
2006 <p>The <, >, <=, >= comparison operator are wrong: they
2007 return the opposite of what they should.</p>
2009 <p>Note: same problem in CD2, these were not even defined in CD1. SGI
2010 STL code is correct; this problem is known since the Morristown
2011 meeting but there it was too late</p>
2014 <p><b>Rationale:</b></p>
2015 <p>This is not a defect in the Standard. A careful reading shows the Standard is correct
2016 as written. A review of several implementations show that they implement
2017 exactly what the Standard says.</p>
2023 <h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
2024 <p><b>Section:</b> 24.5.2 [insert.iterators], 24.6.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2025 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2026 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
2027 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2028 <p><b>Discussion:</b></p>
2029 <p>Overspecified For an insert iterator it, the expression *it is
2030 required to return a reference to it. This is a simple possible
2031 implementation, but as the SGI STL documentation says, not the only
2032 one, and the user should not assume that this is the case.</p>
2035 <p><b>Rationale:</b></p>
2036 <p>The LWG believes this causes no harm and is not a defect in the
2037 standard. The only example anyone could come up with caused some
2038 incorrect code to work, rather than the other way around.</p>
2045 <h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
2046 <p><b>Section:</b> 23.4.1 [vector], 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
2047 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2048 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
2049 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
2050 <p><b>Discussion:</b></p>
2051 <p>Reserve can not free storage, unlike string::reserve</p>
2054 2010-02-13 Alisdair adds:
2060 This issue has been revisited and addressed (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>). This issues should be reclassified to NAD Editorial to reflect
2067 <p><b>Rationale:</b></p>
2068 <p>This is not a defect in the Standard. The LWG has considered this
2069 issue in the past and sees no need to change the Standard. Deque has
2070 no reserve() member function. For vector, shrink-to-fit can be
2071 expressed in a single line of code (where <tt>v</tt> is
2072 <tt>vector<T></tt>):
2076 <p><tt>vector<T>(v).swap(v); // shrink-to-fit v</tt></p>
2084 <h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
2085 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2086 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2087 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
2088 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
2089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2090 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
2091 <p><b>Discussion:</b></p>
2092 <p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
2093 impossible to implement, as it means that if [i, j) = [x], insert in an associative
2094 container is O(1)!</p>
2097 <p><b>Proposed resolution:</b></p>
2098 <p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
2101 <p><b>Rationale:</b></p>
2102 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
2109 <h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
2110 <p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2111 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2112 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
2113 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2114 <p><b>Discussion:</b></p>
2115 <p>It is not clear that undefined behavior applies when pos == size ()
2116 for the non const version.</p>
2119 <p><b>Proposed resolution:</b></p>
2120 <p>Rewrite as: Otherwise, if pos > size () or pos == size () and
2121 the non-const version is used, then the behavior is undefined.</p>
2124 <p><b>Rationale:</b></p>
2125 <p>The Standard is correct. The proposed resolution already appears in
2132 <h3><a name="105"></a>105. fstream ctors argument types desired</h3>
2133 <p><b>Section:</b> 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2134 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2135 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2136 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a></p>
2137 <p><b>Discussion:</b></p>
2140 <p>fstream ctors take a const char* instead of string.<br>
2141 fstream ctors can't take wchar_t</p>
2143 <p>An extension to add a const wchar_t* to fstream would make the
2144 implementation non conforming.</p>
2147 <p><b>Rationale:</b></p>
2148 <p>This is not a defect in the Standard. It might be an
2149 interesting extension for the next Standard. </p>
2155 <h3><a name="107"></a>107. Valarray constructor is strange</h3>
2156 <p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2157 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
2158 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
2159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2160 <p><b>Discussion:</b></p>
2161 <p>The order of the arguments is (elem, size) instead of the normal
2162 (size, elem) in the rest of the library. Since elem often has an
2163 integral or floating point type, both types are convertible to each
2164 other and reversing them leads to a well formed program.</p>
2167 <p><b>Proposed resolution:</b></p>
2168 <p>Inverting the arguments could silently break programs. Introduce
2169 the two signatures (const T&, size_t) and (size_t, const T&),
2170 but make the one we do not want private so errors result in a
2171 diagnosed access violation. This technique can also be applied to STL
2175 <p><b>Rationale:</b></p>
2176 <p>The LWG believes that while the order of arguments is unfortunate,
2177 it does not constitute a defect in the standard. The LWG believes that
2178 the proposed solution will not work for valarray<size_t> and
2179 perhaps other cases.</p>
2185 <h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
2186 <p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2187 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2010-10-29</p>
2188 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
2189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2190 <p><b>Discussion:</b></p>
2191 <p>The member istreambuf_iterator<>::equal is specified to be
2192 unnecessarily inefficient. While this does not affect the efficiency
2193 of conforming implementations of iostreams, because they can
2194 "reach into" the iterators and bypass this function, it does
2195 affect users who use istreambuf_iterators. </p>
2197 <p>The inefficiency results from a too-scrupulous definition, which
2198 requires a "true" result if neither iterator is at eof. In
2199 practice these iterators can only usefully be compared with the
2200 "eof" value, so the extra test implied provides no benefit,
2201 but slows down users' code. </p>
2203 <p>The solution is to weaken the requirement on the function to return
2204 true only if both iterators are at eof. </p>
2212 Reopened by Alisdair.
2216 Post Summit Daniel adds:
2222 Recommend NAD. The proposed wording would violate the axioms of
2223 concept requirement <tt>EqualityComparable</tt> axioms as part of concept <tt>InputIterator</tt>
2224 and more specifically it would violate the explicit wording of
2225 24.2.3 [input.iterators]/7:
2229 If two iterators <tt>a</tt> and <tt>b</tt> of the same type are equal, then either <tt>a</tt>
2230 and <tt>b</tt> are both
2231 dereferenceable or else neither is dereferenceable.
2247 <p><b>Proposed resolution:</b></p>
2248 <p>Replace 24.6.3.5 [istreambuf.iterator::equal],
2252 <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
2253 end-of-stream, regardless of what streambuf object they use. </p>
2259 <p>-1- Returns: true if and only if both iterators are at
2260 end-of-stream, regardless of what streambuf object they use. </p>
2265 <p><b>Rationale:</b></p>
2266 <p>It is not clear that this is a genuine defect. Additionally, the
2267 LWG was reluctant to make a change that would result in
2268 operator== not being a equivalence relation. One consequence of
2269 this change is that an algorithm that's passed the range [i, i)
2270 would no longer treat it as an empty range.</p>
2277 <h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
2278 <p><b>Section:</b> 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2279 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-13 <b>Last modified:</b> 2010-10-29</p>
2280 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
2281 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2282 <p><b>Discussion:</b></p>
2283 <p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
2286 <p>Following the chain of definitions, I find that the various sync functions have defined
2287 semantics for output streams, but no semantics for input streams. On the other hand,
2288 basic_ostream has no sync function. </p>
2290 <p>The sync function should at minimum be added to basic_ostream, for internal
2293 <p>A larger question is whether sync should have assigned semantics for input streams. </p>
2295 <p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
2296 unread input characters to the source. It is a protected member function. The filebuf
2297 version (which is public) has that behavior (it backs up the read pointer). Class
2298 strstreambuf does not override streambuf::sync, and so sync can't be called on a
2301 <p>If we can add corresponding semantics to the various sync functions, we should. If not,
2302 we should remove sync from basic_istream.</p>
2305 <p><b>Rationale:</b></p>
2306 <p>A sync function is not needed in basic_ostream because the flush function provides the
2307 desired functionality.</p>
2309 <p>As for the other points, the LWG finds the standard correct as written.</p>
2316 <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
2317 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2318 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-11-06 <b>Last modified:</b> 2010-10-29</p>
2319 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
2320 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2321 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
2322 <p><b>Discussion:</b></p>
2326 <p>The following code does not compile with the EDG compiler:</p>
2329 <pre>#include <bitset>
2330 using namespace std;
2331 bitset<32> b("111111111");</pre>
2334 <p>If you cast the ctor argument to a string, i.e.:</p>
2337 <pre>bitset<32> b(string("111111111"));</pre>
2340 <p>then it will compile. The reason is that bitset has the following templatized
2344 <pre>template <class charT, class traits, class Allocator>
2345 explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);</pre>
2348 <p>According to the compiler vendor, Steve Adamcyk at EDG, the user
2349 cannot pass this template constructor a <tt>const char*</tt> and
2350 expect a conversion to <tt>basic_string</tt>. The reason is
2351 "When you have a template constructor, it can get used in
2352 contexts where type deduction can be done. Type deduction basically
2353 comes up with exact matches, not ones involving conversions."
2356 <p>I don't think the intention when this constructor became
2357 templatized was for construction from a <tt>const char*</tt> to no
2361 <p><b>Proposed resolution:</b></p>
2362 <p>Add to 20.5 [template.bitset] a bitset constructor declaration</p>
2365 <pre>explicit bitset(const char*);</pre>
2368 <p>and in Section 20.5.1 [bitset.cons] add:</p>
2371 <pre>explicit bitset(const char* str);</pre>
2373 Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
2377 <p><b>Rationale:</b></p>
2378 <p>Although the problem is real, the standard is designed that way so
2379 it is not a defect. Education is the immediate workaround. A future
2380 standard may wish to consider the Proposed Resolution as an
2388 <h3><a name="121"></a>121. Detailed definition for ctype<wchar_t> specialization</h3>
2389 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2390 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
2391 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
2392 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2393 <p><b>Discussion:</b></p>
2394 <p>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> ,
2395 ctype<wchar_t>. </p>
2397 <p>Also Section 22.4.1.1 [locale.ctype] says: </p>
2400 <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and
2401 ctype<wchar_t> , implement character classing appropriate to the implementation's
2402 native character set. </p>
2405 <p>However, Section 22.4.1.3 [facet.ctype.special]
2406 only has a detailed description of the ctype<char> specialization, not the
2407 ctype<wchar_t> specialization. </p>
2410 <p><b>Proposed resolution:</b></p>
2411 <p>Add the ctype<wchar_t> detailed class description to Section
2412 22.4.1.3 [facet.ctype.special]. </p>
2415 <p><b>Rationale:</b></p>
2416 <p>Specialization for wchar_t is not needed since the default is acceptable.</p>
2423 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3>
2424 <p><b>Section:</b> 27.8 [string.streams], 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2425 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2010-10-29</p>
2426 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
2427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2428 <p><b>Discussion:</b></p>
2429 <p>The following question came from Thorsten Herlemann:</p>
2432 <p>You can set a mode when constructing or opening a file-stream or
2433 filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
2434 that mode later on, e.g. in my own operator << or operator
2435 >> or when I want to check whether a file-stream or
2436 file-buffer object passed as parameter is opened for input or output
2437 or binary? Is there no possibility? Is this a design-error in the
2438 standard C++ library? </p>
2441 <p>It is indeed impossible to find out what a stream's or stream
2442 buffer's open mode is, and without that knowledge you don't know
2443 how certain operations behave. Just think of the append mode. </p>
2445 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
2446 current open mode setting. </p>
2449 post Bellevue: Alisdair requested to re-Open.
2460 Neither Howard nor Bill has received a customer request for this.
2463 No consensus for change. The programmer can save this information to the side.
2472 <p><b>Proposed resolution:</b></p>
2473 <p>For stream buffers, add a function to the base class as a non-virtual function
2474 qualified as const to 27.6.2 [streambuf]:</p>
2476 <p> <tt>openmode mode() const</tt>;</p>
2478 <p><b> Returns</b> the current open mode.</p>
2480 <p>With streams, I'm not sure what to suggest. In principle, the mode
2481 could already be returned by <tt>ios_base</tt>, but the mode is only
2482 initialized for file and string stream objects, unless I'm overlooking
2483 anything. For this reason it should be added to the most derived
2484 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
2485 and would be default initialized in <tt>basic_ios<>::init()</tt>.</p>
2488 <p><b>Rationale:</b></p>
2489 <p>This might be an interesting extension for some future, but it is
2490 not a defect in the current standard. The Proposed Resolution is
2491 retained for future reference.</p>
2498 <h3><a name="131"></a>131. list::splice throws nothing</h3>
2499 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2500 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
2501 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
2502 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2503 <p><b>Discussion:</b></p>
2504 <p>What happens if a splice operation causes the size() of a list to grow
2505 beyond max_size()?</p>
2508 <p><b>Rationale:</b></p>
2509 <p>Size() cannot grow beyond max_size(). </p>
2516 <h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
2517 <p><b>Section:</b> 27.7.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2518 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
2519 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2520 <p><b>Discussion:</b></p>
2521 <p>-1- Effects Constructs an object of class basic_iostream, assigning
2522 initial values to the base classes by calling
2523 basic_istream<charT,traits>(sb) (lib.istream) and
2524 basic_ostream<charT,traits>(sb) (lib.ostream)</p>
2526 <p>The called for basic_istream and basic_ostream constructors call
2527 init(sb). This means that the basic_iostream's virtual base class is
2528 initialized twice.</p>
2531 <p><b>Proposed resolution:</b></p>
2532 <p>Change 27.6.1.5.1, paragraph 1 to:</p>
2534 <p>-1- Effects Constructs an object of class basic_iostream, assigning
2535 initial values to the base classes by calling
2536 basic_istream<charT,traits>(sb) (lib.istream).</p>
2539 <p><b>Rationale:</b></p>
2540 <p>The LWG agreed that the <tt> init()</tt> function is called
2541 twice, but said that this is harmless and so not a defect in the
2548 <h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3>
2549 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2550 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-18 <b>Last modified:</b> 2010-10-29</p>
2551 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
2552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2553 <p><b>Discussion:</b></p>
2554 <p>Section 22.4.1.4 [locale.codecvt] specifies that
2555 ctype_byname<char> must be a specialization of the ctype_byname
2558 <p>It is common practice in the standard that specializations of class templates are only
2559 mentioned where the interface of the specialization deviates from the interface of the
2560 template that it is a specialization of. Otherwise, the fact whether or not a required
2561 instantiation is an actual instantiation or a specialization is left open as an
2562 implementation detail. </p>
2564 <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
2565 fact, that ctype_byname<char> is specified as a specialization suggests that there
2566 must be something "special" about it, but it has the exact same interface as the
2567 ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
2568 redundant, at worst misleading - unless I am missing anything. </p>
2570 <p>Naturally, an implementation will most likely implement ctype_byname<char> as a
2571 specialization, because the base class ctype<char> is a specialization with an
2572 interface different from the ctype template, but that's an implementation detail and need
2573 not be mentioned in the standard. </p>
2581 Reopened by Alisdair.
2595 <p><b>Rationale:</b></p>
2596 <p> The standard as written is mildly misleading, but the correct fix
2597 is to deal with the underlying problem in the ctype_byname base class,
2598 not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
2604 <h3><a name="140"></a>140. map<Key, T>::value_type does not satisfy the assignable requirement</h3>
2605 <p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
2606 <b>Submitter:</b> Mark Mitchell <b>Opened:</b> 1999-04-14 <b>Last modified:</b> 2010-10-29</p>
2607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
2608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
2609 <p><b>Discussion:</b></p>
2611 <p>23.2 [container.requirements]<br>
2613 expression return type
2614 pre/post-condition<br>
2615 ------------- -----------
2616 -------------------<br>
2617 X::value_type T
2618
2623 A map satisfies all the requirements of a container.<br>
2625 For a map<Key, T> ... the value_type is pair<const Key, T>.</p>
2628 <p>There's a contradiction here. In particular, `pair<const Key,
2629 T>' is not assignable; the `const Key' cannot be assigned
2630 to. So, map<Key, T>::value_type does not satisfy the
2631 assignable requirement imposed by a container.</p>
2633 <p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
2634 modification of set keys.]</i></p>
2638 <p><b>Rationale:</b></p>
2639 <p>The LWG believes that the standard is inconsistent, but that this
2640 is a design problem rather than a strict defect. May wish to
2641 reconsider for the next standard.</p>
2647 <h3><a name="143"></a>143. C .h header wording unclear</h3>
2648 <p><b>Section:</b> D.7 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2649 <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04 <b>Last modified:</b> 2010-10-29</p>
2650 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2651 <p><b>Discussion:</b></p>
2652 <p>[depr.c.headers] paragraph 2 reads:</p>
2656 <p>Each C header, whose name has the form name.h, behaves as if each
2657 name placed in the Standard library namespace by the corresponding
2658 cname header is also placed within the namespace scope of the
2659 namespace std and is followed by an explicit using-declaration
2660 (_namespace.udecl_)</p>
2664 <p>I think it should mention the global name space somewhere...
2665 Currently, it indicates that name placed in std is also placed in
2668 <p>I don't know what is the correct wording. For instance, if struct
2669 tm is defined in time.h, ctime declares std::tm. However, the current
2670 wording seems ambiguous regarding which of the following would occur
2671 for use of both ctime and time.h:</p>
2693 <p>I think version 1 is intended.</p>
2695 <p><i>[Kona: The LWG agreed that the wording is not clear. It also
2696 agreed that version 1 is intended, version 2 is not equivalent to
2697 version 1, and version 3 is clearly not intended. The example below
2698 was constructed by Nathan Myers to illustrate why version 2 is not
2699 equivalent to version 1.</i></p>
2701 <p><i>Although not equivalent, the LWG is unsure if (2) is enough of
2702 a problem to be prohibited. Points discussed in favor of allowing
2707 <li><i>It may be a convenience to implementors.</i></li>
2708 <li><i>The only cases that fail are structs, of which the C library
2709 contains only a few.</i></li>
2715 <p><b>Example:</b></p>
2719 <pre>#include <time.h>
2720 #include <utility>
2724 make_pair( t, t ); // okay with version 1 due to Koenig lookup
2725 // fails with version 2; make_pair not found
2732 <p><b>Proposed resolution:</b></p>
2734 <p>Replace D.7 [depr.c.headers] paragraph 2 with:</p>
2738 <p> Each C header, whose name has the form name.h, behaves as if each
2739 name placed in the Standard library namespace by the corresponding
2740 cname header is also placed within the namespace scope of the
2741 namespace std by name.h and is followed by an explicit
2742 using-declaration (_namespace.udecl_) in global scope.</p>
2748 <p><b>Rationale:</b></p>
2749 <p> The current wording in the standard is the result of a difficult
2750 compromise that averted delay of the standard. Based on discussions
2751 in Tokyo it is clear that there is no still no consensus on stricter
2752 wording, so the issue has been closed. It is suggested that users not
2753 write code that depends on Koenig lookup of C library functions.</p>
2759 <h3><a name="145"></a>145. adjustfield lacks default value</h3>
2760 <p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2761 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2010-10-29</p>
2762 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
2763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2764 <p><b>Discussion:</b></p>
2765 <p>There is no initial value for the adjustfield defined, although
2766 many people believe that the default adjustment were right. This is a
2767 common misunderstanding. The standard only defines that, if no
2768 adjustment is specified, all the predefined inserters must add fill
2769 characters before the actual value, which is "as if" the
2770 right flag were set. The flag itself need not be set.</p>
2772 <p>When you implement a user-defined inserter you cannot rely on right
2773 being the default setting for the adjustfield. Instead, you must be
2774 prepared to find none of the flags set and must keep in mind that in
2775 this case you should make your inserter behave "as if" the
2776 right flag were set. This is surprising to many people and complicates
2777 matters more than necessary.</p>
2779 <p>Unless there is a good reason why the adjustfield should not be
2780 initialized I would suggest to give it the default value that
2781 everybody expects anyway.</p>
2785 <p><b>Rationale:</b></p>
2786 <p>This is not a defect. It is deliberate that the default is no bits
2787 set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
2793 <h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
2794 <p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2795 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
2796 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
2797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2798 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
2799 <p><b>Discussion:</b></p>
2800 <p>According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the
2801 functions <tt>iword()</tt> and <tt>pword()</tt> "set the
2802 <tt>badbit</tt> (which might throw an exception)" on
2803 failure. ... but what does it mean for <tt>ios_base</tt> to set the
2804 <tt>badbit</tt>? The state facilities of the IOStream library are
2805 defined in <tt>basic_ios</tt>, a derived class! It would be possible
2806 to attempt a down cast but then it would be necessary to know the
2807 character type used...</p>
2810 <p><b>Rationale:</b></p>
2817 <h3><a name="162"></a>162. Really "formatted input functions"?</h3>
2818 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2819 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
2820 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
2821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2822 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2823 <p><b>Discussion:</b></p>
2824 <p>It appears to be somewhat nonsensical to consider the functions
2825 defined in the paragraphs 1 to 5 to be "Formatted input
2826 function" but since these functions are defined in a section
2827 labeled "Formatted input functions" it is unclear to me
2828 whether these operators are considered formatted input functions which
2829 have to conform to the "common requirements" from 27.7.1.2.1 [istream.formatted.reqmts]: If this is the case, all manipulators, not just
2830 <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
2831 (... but setting <tt>noskipws</tt> using the manipulator syntax would
2832 also skip whitespace :-)</p>
2834 <p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
2838 <p><b>Rationale:</b></p>
2845 <h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
2846 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2847 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
2848 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
2849 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2850 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2851 <p><b>Discussion:</b></p>
2852 <p>It is not clear which functions are to be considered unformatted
2853 input functions. As written, it seems that all functions in 27.7.1.3 [istream.unformatted] are unformatted input functions. However, it does not
2854 really make much sense to construct a sentry object for
2855 <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
2856 happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
2857 <tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
2858 These functions don't extract characters, some of them even
2859 "unextract" a character. Should this still be reflected in
2860 <tt>gcount()</tt>? Of course, it could be read as if after a call to
2861 <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
2862 unformatted input function, <tt>gcount()</tt>, didn't extract any
2863 character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
2864 returns <tt>-1</tt> (the last unformatted input function
2865 <tt>putback()</tt> did "extract" back into the
2866 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2867 intended? If so, this should be clarified. Otherwise, a corresponding
2868 clarification should be used.</p>
2871 <p><b>Rationale:</b></p>
2878 <h3><a name="166"></a>166. Really "formatted output functions"?</h3>
2879 <p><b>Section:</b> 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2880 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
2881 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2882 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2883 <p><b>Discussion:</b></p>
2884 <p>From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
2885 defined in 27.7.2.6.3 [ostream.inserters] have to construct a
2886 <tt>sentry</tt> object. Is this really intended?</p>
2888 <p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
2889 for output instead of input.</p>
2892 <p><b>Rationale:</b></p>
2899 <h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
2900 <p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2901 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02 <b>Last modified:</b> 2010-10-29</p>
2902 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
2903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2904 <p><b>Discussion:</b></p>
2905 <p>A user who tries to explicitly instantiate a complex non-member operator will
2906 get compilation errors. Below is a simplified example of the reason why. The
2907 problem is that iterator_traits cannot be instantiated on a non-pointer type
2908 like float, yet when the compiler is trying to decide which operator+ needs to
2909 be instantiated it must instantiate the declaration to figure out the first
2910 argument type of a reverse_iterator operator.</p>
2911 <pre>namespace std {
2912 template <class Iterator>
2913 struct iterator_traits
2915 typedef typename Iterator::value_type value_type;
2918 template <class T> class reverse_iterator;
2920 // reverse_iterator operator+
2921 template <class T>
2922 reverse_iterator<T> operator+
2923 (typename iterator_traits<T>::difference_type, const reverse_iterator<T>&);
2925 template <class T> struct complex {};
2927 // complex operator +
2928 template <class T>
2929 complex<T> operator+ (const T& lhs, const complex<T>& rhs)
2930 { return complex<T>();}
2933 // request for explicit instantiation
2934 template std::complex<float> std::operator+<float>(const float&,
2935 const std::complex<float>&);</pre>
2936 <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2939 <p><b>Rationale:</b></p>
2940 <p>Implementors can make minor changes and the example will
2941 work. Users are not affected in any case.</p> <p>According to John
2942 Spicer, It is possible to explicitly instantiate these operators using
2943 different syntax: change "std::operator+<float>" to
2944 "std::operator+".</p>
2946 <p>The proposed resolution of issue 120 is that users will not be able
2947 to explicitly instantiate standard library templates. If that
2948 resolution is accepted then library implementors will be the only ones
2949 that will be affected by this problem, and they must use the indicated
2956 <h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
2957 <p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2958 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02 <b>Last modified:</b> 2010-10-29</p>
2959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
2960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2961 <p><b>Discussion:</b></p>
2963 Section 27.3.1 says "After the object cerr is initialized,
2964 cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as
2965 required for ios_base::init (lib.basic.ios.cons). It doesn't say
2966 anything about the the state of clog. So this means that calling
2967 cerr.tie() and clog.tie() should return 0 (see Table 89 for
2968 ios_base::init effects).
2971 Neither of the popular standard library implementations
2972 that I tried does this, they both tie cerr and clog
2973 to &cout. I would think that would be what users expect.
2977 <p><b>Rationale:</b></p>
2978 <p>The standard is clear as written.</p>
2979 <p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
2980 & unitbuf is nonzero. Its state is otherwise the same as required for
2981 ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
2982 postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
2983 ios_base::init to basic_ios::init().)</p>
2989 <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
2990 <p><b>Section:</b> 26.6.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2991 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-08-15 <b>Last modified:</b> 2010-10-29</p>
2992 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cassign">issues</a> in [valarray.cassign].</p>
2993 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2994 <p><b>Discussion:</b></p>
2995 <p>26.5.2.6 defines augmented assignment operators
2996 valarray<T>::op=(const T&), but fails to provide
2997 corresponding versions for the helper classes. Thus making the
2998 following illegal:</p>
3000 <pre>#include <valarray>
3004 std::valarray<double> v(3.14, 1999);
3008 std::slice s(0, 50, 2);
3010 v[s] *= 2.0; // ERROR
3013 <p>I can't understand the intent of that omission. It makes the
3014 valarray library less intuitive and less useful.</p>
3017 <p><b>Rationale:</b></p>
3018 <p>Although perhaps an unfortunate
3019 design decision, the omission is not a defect in the current
3020 standard. A future standard may wish to add the missing
3027 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
3028 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3029 <b>Submitter:</b> Mark Rintoul <b>Opened:</b> 1999-08-26 <b>Last modified:</b> 2010-10-29</p>
3030 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
3031 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3032 <p><b>Discussion:</b></p>
3033 <p>Both std::min and std::max are defined as template functions. This
3034 is very different than the definition of std::plus (and similar
3035 structs) which are defined as function objects which inherit
3036 std::binary_function.<br>
3038 This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
3039 a function object that inherits std::binary_function.</p>
3042 post Bellevue: Alisdair requested to re-Open.
3053 C++0x has lambdas to address this problem now.
3062 <p><b>Rationale:</b></p>
3063 <p>Although perhaps an unfortunate design decision, the omission is not a defect
3064 in the current standard. A future standard may wish to consider additional
3065 function objects.</p>
3071 <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
3072 <p><b>Section:</b> 25.4.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3073 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1999-10-10 <b>Last modified:</b> 2010-10-29</p>
3074 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
3075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3076 <p><b>Discussion:</b></p>
3077 <p>The complexity of binary_search() is stated as "At most
3078 log(last-first) + 2 comparisons", which seems to say that the
3079 algorithm has logarithmic complexity. However, this algorithms is
3080 defined for forward iterators. And for forward iterators, the need to
3081 step element-by-element results into linear complexity. But such a
3082 statement is missing in the standard. The same applies to
3083 lower_bound(), upper_bound(), and equal_range(). <br>
3085 However, strictly speaking the standard contains no bug here. So this
3086 might considered to be a clarification or improvement.
3090 <p><b>Rationale:</b></p>
3091 <p>The complexity is expressed in terms of comparisons, and that
3092 complexity can be met even if the number of iterators accessed is
3093 linear. Paragraph 1 already says exactly what happens to
3100 <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
3101 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3102 <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-06 <b>Last modified:</b> 2010-10-29</p>
3103 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
3104 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
3105 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3106 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
3107 <p><b>Discussion:</b></p>
3108 <p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
3109 several problems:</p>
3110 <table border="1" cellpadding="5">
3112 <td><b>expression</b></td>
3113 <td><b>return type</b></td>
3114 <td><b>pre/post-condition</b></td>
3115 <td><b>complexity</b></td>
3118 <td><tt>a.insert(p,t)</tt></td>
3119 <td><tt>iterator</tt></td>
3120 <td>inserts t if and only if there is no element with key equivalent to the key of
3121 t in containers with unique keys; always inserts t in containers with equivalent
3122 keys. always returns the iterator pointing to the element with key equivalent to
3123 the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
3124 <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
3127 <p>1. For a container with unique keys, only logarithmic complexity is
3128 guaranteed if no element is inserted, even though constant complexity is always
3129 possible if p points to an element equivalent to t.</p>
3130 <p>2. For a container with equivalent keys, the amortized constant complexity
3131 guarantee is only useful if no key equivalent to t exists in the container.
3132 Otherwise, the insertion could occur in one of multiple locations, at least one
3133 of which would not be right after p.</p>
3134 <p>3. By guaranteeing amortized constant complexity only when t is inserted
3135 after p, it is impossible to guarantee constant complexity if t is inserted at
3136 the beginning of the container. Such a problem would not exist if amortized
3137 constant complexity was guaranteed if t is inserted before p, since there is
3138 always some p immediately before which an insert can take place.</p>
3139 <p>4. For a container with equivalent keys, p does not allow specification of
3140 where to insert the element, but rather only acts as a hint for improving
3141 performance. This negates the added functionality that p would provide if it
3142 specified where within a sequence of equivalent keys the insertion should occur.
3143 Specifying the insert location provides more control to the user, while
3144 providing no disadvantage to the container implementation.</p>
3147 <p><b>Proposed resolution:</b></p>
3148 <p>In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69
3149 for a.insert(p,t) with the following two rows:</p>
3150 <table border="1" cellpadding="5">
3152 <td><b>expression</b></td>
3153 <td><b>return type</b></td>
3154 <td><b>pre/post-condition</b></td>
3155 <td><b>complexity</b></td>
3158 <td><tt>a_uniq.insert(p,t)</tt></td>
3159 <td><tt>iterator</tt></td>
3160 <td>inserts t if and only if there is no element with key equivalent to the
3161 key of t. returns the iterator pointing to the element with key equivalent
3162 to the key of t.</td>
3163 <td>logarithmic in general, but amortized constant if t is inserted right
3164 before p or p points to an element with key equivalent to t.</td>
3167 <td><tt>a_eq.insert(p,t)</tt></td>
3168 <td><tt>iterator</tt></td>
3169 <td>inserts t and returns the iterator pointing to the newly inserted
3170 element. t is inserted right before p if doing so preserves the container
3172 <td>logarithmic in general, but amortized constant if t is inserted right
3179 <p><b>Rationale:</b></p>
3180 <p>Too big a change. Furthermore, implementors report checking
3181 both before p and after p, and don't want to change this behavior.</p>
3188 <h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
3189 <p><b>Section:</b> 27.5.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3190 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1999-09-07 <b>Last modified:</b> 2010-10-29</p>
3191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3192 <p><b>Discussion:</b></p>
3193 <p>In classic iostreams, base class ios had an rdbuf function that returned a
3194 pointer to the associated streambuf. Each derived class had its own rdbuf
3195 function that returned a pointer of a type reflecting the actual type derived
3196 from streambuf. Because in ARM C++, virtual function overrides had to have the
3197 same return type, rdbuf could not be virtual.</p>
3198 <p>In standard iostreams, we retain the non-virtual rdbuf function design, and
3199 in addition have an overloaded rdbuf function that sets the buffer pointer.
3200 There is no need for the second function to be virtual nor to be implemented in
3201 derived classes.</p>
3202 <p>Minor question: Was there a specific reason not to make the original rdbuf
3203 function virtual?</p>
3204 <p>Major problem: Friendly compilers warn about functions in derived classes
3205 that hide base-class overloads. Any standard implementation of iostreams will
3206 result in such a warning on each of the iostream classes, because of the
3207 ill-considered decision to overload rdbuf only in a base class.</p>
3208 <p>In addition, users of the second rdbuf function must use explicit
3209 qualification or a cast to call it from derived classes. An explicit
3210 qualification or cast to basic_ios would prevent access to any later overriding
3211 version if there was one.</p>
3212 <p>What I'd like to do in an implementation is add a using- declaration for the
3213 second rdbuf function in each derived class. It would eliminate warnings about
3214 hiding functions, and would enable access without using explicit qualification.
3215 Such a change I don't think would change the behavior of any valid program, but
3216 would allow invalid programs to compile:</p>
3218 <pre> filebuf mybuf;
3220 f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
3222 <p>I'd like to suggest this problem as a defect, with the proposed resolution to
3223 require the equivalent of a using-declaration for the rdbuf function that is not
3224 replaced in a later derived class. We could discuss whether replacing the
3225 function should be allowed.</p>
3228 <p><b>Rationale:</b></p>
3229 <p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
3230 class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
3231 class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
3232 <tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
3234 <p>Permission is not required to add such an extension. See
3235 17.6.4.5 [member.functions].</p>
3241 <h3><a name="196"></a>196. Placement new example has alignment problems</h3>
3242 <p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3243 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
3244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
3245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3246 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
3247 <p><b>Discussion:</b></p>
3248 <p>The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: </p>
3252 <p>[Example: This can be useful for constructing an object at a known address:<br>
3254 <tt> char place[sizeof(Something)];<br>
3255 Something* p = new (place) Something();<br>
3257 </tt>end example] </p>
3261 <p>This example has potential alignment problems. </p>
3264 <p><b>Rationale:</b></p>
3271 <h3><a name="197"></a>197. max_size() underspecified</h3>
3272 <p><b>Section:</b> 20.2.5 [allocator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3273 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-10-21 <b>Last modified:</b> 2010-10-29</p>
3274 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
3275 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3276 <p><b>Discussion:</b></p>
3277 <p>Must the value returned by max_size() be unchanged from call to call? </p>
3279 <p>Must the value returned from max_size() be meaningful? </p>
3281 <p>Possible meanings identified in lib-6827: </p>
3283 <p>1) The largest container the implementation can support given "best
3284 case" conditions - i.e. assume the run-time platform is "configured to
3285 the max", and no overhead from the program itself. This may possibly
3286 be determined at the point the library is written, but certainly no
3287 later than compile time.<br>
3289 2) The largest container the program could create, given "best case"
3290 conditions - i.e. same platform assumptions as (1), but take into
3291 account any overhead for executing the program itself. (or, roughly
3292 "storage=storage-sizeof(program)"). This does NOT include any resource
3293 allocated by the program. This may (or may not) be determinable at
3296 3) The largest container the current execution of the program could
3297 create, given knowledge of the actual run-time platform, but again,
3298 not taking into account any currently allocated resource. This is
3299 probably best determined at program start-up.<br>
3301 4) The largest container the current execution program could create at
3302 the point max_size() is called (or more correctly at the point
3303 max_size() returns :-), given it's current environment (i.e. taking
3304 into account the actual currently available resources). This,
3305 obviously, has to be determined dynamically each time max_size() is
3309 <p><b>Proposed resolution:</b></p>
3312 <p><b>Rationale:</b></p>
3313 <p>max_size() isn't useful for very many things, and the existing
3314 wording is sufficiently clear for the few cases that max_size() can
3315 be used for. None of the attempts to change the existing wording
3316 were an improvement.</p>
3318 <p>It is clear to the LWG that the value returned by max_size() can't
3319 change from call to call.</p>
3327 <h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></h3>
3328 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3329 <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Opened:</b> 2000-01-01 <b>Last modified:</b> 2010-10-29</p>
3330 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
3331 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3332 <p><b>Discussion:</b></p>
3333 <p>27.6.1.1.2 Paragraph 4 states:</p>
3335 <p>To decide if the character c is a whitespace character, the constructor
3336 performs ''as if'' it executes the following code fragment: </p>
3337 <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc());
3338 if (ctype.is(ctype.space,c)!=0)
3339 // c is a whitespace character.</pre>
3342 <p> But Table 51 in 22.1.1.1.1 only requires an implementation to
3343 provide specializations for ctype<char> and
3344 ctype<wchar_t>. If sentry's constructor is implemented using
3345 ctype, it will be uninstantiable for a user-defined character type
3346 charT, unless the implementation has provided non-working (since it
3347 would be impossible to define a correct ctype<charT> specialization
3348 for an arbitrary charT) definitions of ctype's virtual member
3352 It seems the intent the standard is that sentry should behave, in
3353 every respect, not just during execution, as if it were implemented
3354 using ctype, with the burden of providing a ctype specialization
3355 falling on the user. But as it is written, nothing requires the
3356 translation of sentry's constructor to behave as if it used the above
3357 code, and it would seem therefore, that sentry's constructor should be
3358 instantiable for all character types.
3362 Note: If I have misinterpreted the intent of the standard with
3363 respect to sentry's constructor's instantiability, then a note should
3364 be added to the following effect:
3368 An implementation is forbidden from using the above code if it renders
3369 the constructor uninstantiable for an otherwise valid character
3373 <p>In any event, some clarification is needed.</p>
3377 <p><b>Rationale:</b></p>
3378 <p>It is possible but not easy to instantiate on types other than char
3379 or wchar_t; many things have to be done first. That is by intention
3380 and is not a defect.</p>
3386 <h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
3387 <p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3388 <b>Submitter:</b> Rintala Matti <b>Opened:</b> 2000-01-28 <b>Last modified:</b> 2010-10-29</p>
3389 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
3390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3391 <p><b>Discussion:</b></p>
3392 <p>Section 24.3.4 describes the function distance(first, last) (where first and
3393 last are iterators) which calculates "the number of increments or
3394 decrements needed to get from 'first' to 'last'".</p>
3395 <p>The function should work for forward, bidirectional and random access
3396 iterators, and there is a requirement 24.3.4.5 which states that "'last'
3397 must be reachable from 'first'".</p>
3398 <p>With random access iterators the function is easy to implement as "last
3400 <p>With forward iterators it's clear that 'first' must point to a place before
3401 'last', because otherwise 'last' would not be reachable from 'first'.</p>
3402 <p>But what about bidirectional iterators? There 'last' is reachable from
3403 'first' with the -- operator even if 'last' points to an earlier position than
3404 'first'. However, I cannot see how the distance() function could be implemented
3405 if the implementation does not know which of the iterators points to an earlier
3406 position (you cannot use ++ or -- on either iterator if you don't know which
3407 direction is the "safe way to travel").</p>
3408 <p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
3409 use ++ to provide linear time implementations". However, the ++ operator is
3410 not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
3411 mentions that distance() returns the number of increments _or decrements_,
3412 suggesting that it could return a negative number also for bidirectional
3413 iterators when 'last' points to a position before 'first'.</p>
3414 <p>Is a further requirement is needed to state that for forward and
3415 bidirectional iterators "'last' must be reachable from 'first' using the ++
3416 operator". Maybe this requirement might also apply to random access
3417 iterators so that distance() would work the same way for every iterator
3421 <p><b>Rationale:</b></p>
3422 <p>"Reachable" is defined in the standard in X [iterator.concepts] paragraph 6.
3423 The definition is only in terms of operator++(). The LWG sees no defect in
3430 <h3><a name="205"></a>205. numeric_limits unclear on how to determine floating point types</h3>
3431 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3432 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-01-28 <b>Last modified:</b> 2010-10-29</p>
3433 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
3434 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3435 <p><b>Discussion:</b></p>
3436 <p>In several places in 18.3.1.2 [numeric.limits.members], a member is
3437 described as "Meaningful for all floating point types."
3438 However, no clear method of determining a floating point type is
3441 <p>In 18.3.1.5 [numeric.special], paragraph 1 states ". . . (for
3442 example, epsilon() is only meaningful if is_integer is
3443 false). . ." which suggests that a type is a floating point type
3444 if is_specialized is true and is_integer is false; however, this is
3447 <p>When clarifying this, please keep in mind this need of users: what
3448 exactly is the definition of floating point? Would a fixed point or
3449 rational representation be considered one? I guess my statement here
3450 is that there could also be types that are neither integer or
3451 (strictly) floating point.</p>
3454 <p><b>Rationale:</b></p>
3455 <p>It is up to the implementor of a user define type to decide if it is a
3456 floating point type.</p>
3462 <h3><a name="207"></a>207. ctype<char> members return clause incomplete</h3>
3463 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3464 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 1999-11-02 <b>Last modified:</b> 2010-10-29</p>
3465 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
3466 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3467 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
3468 <p><b>Discussion:</b></p>
3470 The <tt>widen</tt> and <tt>narrow</tt> member functions are described
3471 in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded
3472 signatures followed by a <b>Returns</b> clause. The <b>Returns</b>
3473 clause only describes one of the overloads.
3477 <p><b>Proposed resolution:</b></p>
3478 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
3479 paragraph 10 from:</p>
3480 <p> Returns: do_widen(low, high, to).</p>
3483 <p> Returns: do_widen(c) or do_widen(low, high, to),
3486 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
3488 <p> Returns: do_narrow(low, high, to).</p>
3491 <p> Returns: do_narrow(c) or do_narrow(low, high, to),
3495 <p><b>Rationale:</b></p>
3496 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
3505 <h3><a name="213"></a>213. Math function overloads ambiguous</h3>
3506 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3507 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2010-10-29</p>
3508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
3509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3510 <p><b>Discussion:</b></p>
3511 <p>Due to the additional overloaded versions of numeric functions for
3512 float and long double according to Section 26.5, calls such as int x;
3513 std::pow (x, 4) are ambiguous now in a standard conforming
3514 implementation. Current implementations solve this problem very
3515 different (overload for all types, don't overload for float and long
3516 double, use preprocessor, follow the standard and get
3517 ambiguities).</p> <p>This behavior should be standardized or at least
3518 identified as implementation defined.</p>
3521 <p><b>Rationale:</b></p>
3522 <p>These math issues are an
3523 understood and accepted consequence of the design. They have
3524 been discussed several times in the past. Users must write casts
3525 or write floating point expressions as arguments.</p>
3531 <h3><a name="215"></a>215. Can a map's key_type be const?</h3>
3532 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3533 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2010-10-29</p>
3534 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
3535 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
3536 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3537 <p><b>Discussion:</b></p>
3538 <p>A user noticed that this doesn't compile with the Rogue Wave library because
3539 the rb_tree class declares a key_allocator, and allocator<const int> is
3540 not legal, I think:</p>
3542 <pre>map < const int, ... > // legal?</pre>
3544 <p>which made me wonder whether it is legal for a map's key_type to be const. In
3545 email from Matt Austern he said:</p>
3547 <p>I'm not sure whether it's legal to declare a map with a const key type. I
3548 hadn't thought about that question until a couple weeks ago. My intuitive
3549 feeling is that it ought not to be allowed, and that the standard ought to say
3550 so. It does turn out to work in SGI's library, though, and someone in the
3551 compiler group even used it. Perhaps this deserves to be written up as an issue
3556 <p><b>Rationale:</b></p>
3557 <p>The "key is assignable" requirement from table 69 in
3558 23.2.4 [associative.reqmts] already implies the key cannot be const.</p>
3564 <h3><a name="216"></a>216. setbase manipulator description flawed</h3>
3565 <p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3566 <b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2010-10-29</p>
3567 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
3568 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3569 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
3570 <p><b>Discussion:</b></p>
3571 <p>27.7.3 [std.manip] paragraph 5 says:</p>
3573 <pre>smanip setbase(int base);</pre>
3574 <p> Returns: An object s of unspecified type such that if out is an
3575 (instance of) basic_ostream then the expression out<<s behaves
3576 as if f(s) were called, in is an (instance of) basic_istream then the
3577 expression in>>s behaves as if f(s) were called. Where f can be
3579 <pre>ios_base& f(ios_base& str, int base)
3582 str.setf(n == 8 ? ios_base::oct :
3583 n == 10 ? ios_base::dec :
3584 n == 16 ? ios_base::hex :
3585 ios_base::fmtflags(0), ios_base::basefield);
3589 <p>There are two problems here. First, f takes two parameters, so the
3590 description needs to say that out<<s and in>>s behave as if f(s,base)
3591 had been called. Second, f is has a parameter named base, but is written as if
3592 the parameter was named n.</p>
3593 <p>Actually, there's a third problem. The paragraph has grammatical errors.
3594 There needs to be an "and" after the first comma, and the "Where
3595 f" sentence fragment needs to be merged into its preceding sentence. You
3596 may also want to format the function a little better. The formatting above is
3597 more-or-less what the Standard contains.</p>
3600 <p><b>Rationale:</b></p>
3601 <p>The resolution of this defect is subsumed by the proposed resolution for
3602 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
3604 <p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
3605 occurs additional places in the section, all requiring fixes.]</i></p>
3615 <h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
3616 <p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3617 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06 <b>Last modified:</b> 2010-10-29</p>
3618 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
3619 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3620 <p><b>Discussion:</b></p>
3621 <p>Many of the algorithms take an argument, pred, of template parameter type
3622 BinaryPredicate or an argument comp of template parameter type Compare. These
3623 algorithms usually have an overloaded version that does not take the predicate
3624 argument. In these cases pred is usually replaced by the use of operator== and
3625 comp is replaced by the use of operator<.</p>
3626 <p>This use of hard-coded operators is inconsistent with other parts of the
3627 library, particularly the containers library, where equality is established
3628 using equal_to<> and ordering is established using less<>. Worse,
3629 the use of operator<, would cause the following innocent-looking code to have
3630 undefined behavior:</p>
3632 <pre>vector<string*> vec;
3633 sort(vec.begin(), vec.end());</pre>
3635 <p>The use of operator< is not defined for pointers to unrelated objects. If
3636 std::sort used less<> to compare elements, then the above code would be
3637 well-defined, since less<> is explicitly specialized to produce a total
3638 ordering of pointers.</p>
3641 <p><b>Rationale:</b></p>
3642 <p>This use of operator== and operator< was a very deliberate, conscious, and
3643 explicitly made design decision; these operators are often more efficient. The
3644 predicate forms are available for users who don't want to rely on operator== and
3651 <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
3652 <p><b>Section:</b> 25.2.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3653 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06 <b>Last modified:</b> 2010-10-29</p>
3654 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
3655 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3656 <p><b>Discussion:</b></p>
3657 <p>The find function always searches for a value using operator== to compare the
3658 value argument to each element in the input iterator range. This is inconsistent
3659 with other find-related functions such as find_end and find_first_of, which
3660 allow the caller to specify a binary predicate object to be used for determining
3661 equality. The fact that this can be accomplished using a combination of find_if
3662 and bind_1st or bind_2nd does not negate the desirability of a consistent,
3663 simple, alternative interface to find.</p>
3671 Reopened by Alisdair.
3681 The same thing can be achieved using find_if (as noted in the issue).
3690 <p><b>Proposed resolution:</b></p>
3692 <p>In section 25.2.5 [alg.find], add a second prototype for find
3693 (between the existing prototype and the prototype for find_if), as
3695 <pre> template<class InputIterator, class T, class BinaryPredicate>
3696 InputIterator find(InputIterator first, InputIterator last,
3697 const T& value, BinaryPredicate bin_pred);</pre>
3698 <p>Change the description of the return from:</p>
3700 <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
3701 conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
3705 <p>Returns: The first iterator i in the range [first, last) for which the following
3706 corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
3707 != false. Return last if no such iterator is found.</p>
3712 <p><b>Rationale:</b></p>
3713 <p>This is request for a pure extension, so it is not a defect in the
3714 current standard. As the submitter pointed out, "this can
3715 be accomplished using a combination of find_if and bind_1st or
3722 <h3><a name="236"></a>236. ctype<char>::is() member modifies facet</h3>
3723 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3724 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
3725 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
3726 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3727 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
3728 <p><b>Discussion:</b></p>
3729 <p>The description of the <tt>is()</tt> member in paragraph 4 of 22.4.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
3730 second form of the <tt>is()</tt> method modifies the masks in the
3731 <tt>ctype</tt> object. The correct semantics if, of course, to obtain
3732 an array of masks. The corresponding method in the general case,
3733 ie. the <tt>do_is()</tt> method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
3736 <p><b>Proposed resolution:</b></p>
3737 <p>Change paragraph 4 from</p>
3739 The second form, for all *p in the range [low, high), assigns
3740 vec[p-low] to table()[(unsigned char)*p].
3744 The second form, for all *p in the range [low, high), assigns
3745 table()[(unsigned char)*p] to vec[p-low].
3749 <p><b>Rationale:</b></p>
3756 <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
3757 <p><b>Section:</b> 25.2.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3758 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02 <b>Last modified:</b> 2010-10-29</p>
3759 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
3760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3761 <p><b>Discussion:</b></p>
3762 <p>Is the following implementation of <tt>find</tt> acceptable?</p>
3764 <pre> template<class Iter, class X>
3765 Iter find(Iter begin, Iter end, const X& x)
3767 X x1 = x; // this is the crucial statement
3768 while (begin != end && *begin != x1)
3774 <p>If the answer is yes, then it is implementation-dependent as to
3775 whether the following fragment is well formed:</p>
3777 <pre> vector<string> v;
3779 find(v.begin(), v.end(), "foo");
3782 <p>At issue is whether there is a requirement that the third argument
3783 of find be CopyConstructible. There may be no problem here, but
3784 analysis is necessary.</p>
3787 <p><b>Rationale:</b></p>
3788 <p>There is no indication in the standard that find's third argument
3789 is required to be Copy Constructible. The LWG believes that no such
3790 requirement was intended. As noted above, there are times when a user
3791 might reasonably pass an argument that is not Copy Constructible.</p>
3797 <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
3798 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3799 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02 <b>Last modified:</b> 2010-10-29</p>
3800 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
3801 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3802 <p><b>Discussion:</b></p>
3803 <p>I do not think the standard specifies what operation(s) on istream
3804 iterators trigger input operations. So, for example:</p>
3806 <pre> istream_iterator<int> i(cin);
3811 <p>I do not think it is specified how many integers have been read
3812 from cin. The number must be at least 1, of course, but can it be 2?
3816 <p><b>Rationale:</b></p>
3817 <p>The standard is clear as written: the stream is read every time
3818 operator++ is called, and it is also read either when the iterator is
3819 constructed or when operator* is called for the first time. In the
3820 example above, exactly two integers are read from cin.</p>
3822 <p>There may be a problem with the interaction between istream_iterator
3823 and some STL algorithms, such as find. There are no guarantees about
3824 how many times find may invoke operator++.</p>
3830 <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
3831 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3832 <b>Submitter:</b> Mark Rodgers <b>Opened:</b> 2000-05-19 <b>Last modified:</b> 2010-10-29</p>
3833 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
3834 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
3835 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3836 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
3837 <p><b>Discussion:</b></p>
3838 <p>Closed issue 192 raised several problems with the specification of
3839 this function, but was rejected as Not A Defect because it was too big
3840 a change with unacceptable impacts on existing implementations.
3841 However, issues remain that could be addressed with a smaller change
3842 and with little or no consequent impact.</p>
3845 <li><p> The specification is inconsistent with the original
3846 proposal and with several implementations.</p>
3848 <p>The initial implementation by Hewlett Packard only ever looked
3849 immediately <i>before</i> p, and I do not believe there was any
3850 intention to standardize anything other than this behavior.
3851 Consequently, current implementations by several leading
3852 implementors also look immediately before p, and will only insert
3853 after p in logarithmic time. I am only aware of one implementation
3854 that does actually look after p, and it looks before p as well. It
3855 is therefore doubtful that existing code would be relying on the
3856 behavior defined in the standard, and it would seem that fixing
3857 this defect as proposed below would standardize existing
3861 The specification is inconsistent with insertion for sequence
3864 <p>This is difficult and confusing to teach to newcomers. All
3865 insert operations that specify an iterator as an insertion location
3866 should have a consistent meaning for the location represented by
3867 that iterator.</p></li>
3869 <li><p> As specified, there is no way to hint that the insertion
3870 should occur at the beginning of the container, and the way to hint
3871 that it should occur at the end is long winded and unnatural.</p>
3873 <p>For a container containing n elements, there are n+1 possible
3874 insertion locations and n+1 valid iterators. For there to be a
3875 one-to-one mapping between iterators and insertion locations, the
3876 iterator must represent an insertion location immediately before
3877 the iterator.</p></li>
3879 <li><p> When appending sorted ranges using insert_iterators,
3880 insertions are guaranteed to be sub-optimal.</p>
3882 <p>In such a situation, the optimum location for insertion is
3883 always immediately after the element previously inserted. The
3884 mechanics of the insert iterator guarantee that it will try and
3885 insert after the element after that, which will never be correct.
3886 However, if the container first tried to insert before the hint,
3887 all insertions would be performed in amortized constant
3892 <p><b>Proposed resolution:</b></p>
3893 <p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
3894 the following changes in the row for a.insert(p,t):</p>
3896 <p><i>assertion/note pre/post condition:</i>
3897 <br>Change the last sentence from</p>
3899 "iterator p is a hint pointing to where the insert should
3904 "iterator p is a hint indicating that immediately before p
3905 may be a correct location where the insertion could occur."
3908 <p><i>complexity:</i><br>
3909 Change the words "right after" to "immediately before".</p>
3912 <p><b>Rationale:</b></p>
3919 <h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
3920 <p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3921 <b>Submitter:</b> Joseph Gottman <b>Opened:</b> 2000-06-30 <b>Last modified:</b> 2010-10-29</p>
3922 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
3923 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3924 <p><b>Discussion:</b></p>
3925 <p>According to section 20.4.5, the function
3926 <tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
3927 The reason that <tt>operator=()</tt> usually returns a reference is to
3928 facilitate code like</p>
3934 <p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3935 <pre> auto_ptr<int> x, y, z;
3936 z.reset(new int(1));
3940 <p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
3941 NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
3942 This makes such cascading assignments useless and counterintuitive for
3943 <tt>auto_ptr</tt>s.</p>
3946 <p><b>Proposed resolution:</b></p>
3947 <p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
3948 of an <tt>auto_ptr</tt> reference.</p>
3951 <p><b>Rationale:</b></p>
3952 <p>The return value has uses other than cascaded assignments: a user can
3953 call an auto_ptr member function, pass the auto_ptr to a
3954 function, etc. Removing the return value could break working user
3961 <h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
3962 <p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
3963 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-12 <b>Last modified:</b> 2010-10-29</p>
3964 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
3965 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
3966 <p><b>Discussion:</b></p>
3968 The basic_streambuf members gbump() and pbump() are specified to take an
3969 int argument. This requirement prevents the functions from effectively
3970 manipulating buffers larger than std::numeric_limits<int>::max()
3971 characters. It also makes the common use case for these functions
3972 somewhat difficult as many compilers will issue a warning when an
3973 argument of type larger than int (such as ptrdiff_t on LLP64
3974 architectures) is passed to either of the function. Since it's often the
3975 result of the subtraction of two pointers that is passed to the
3976 functions, a cast is necessary to silence such warnings. Finally, the
3977 usage of a native type in the functions signatures is inconsistent with
3978 other member functions (such as sgetn() and sputn()) that manipulate the
3979 underlying character buffer. Those functions take a streamsize argument.
3989 This is part of a bigger problem. If anyone cares enough, they should
3990 write a paper solving the bigger problem of offset types in iostreams.
3993 This is related to the paper about large file sizes. Beman has already
3994 agreed to drop the section of that paper that deals with this.
3997 int is big enough for reasonable buffers.
4003 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>.
4009 <p><b>Proposed resolution:</b></p>
4011 Change the signatures of these functions in the synopsis of template
4012 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
4013 and 27.5.2.3.2, p4) to take a streamsize argument.
4017 Although this change has the potential of changing the ABI of the
4018 library, the change will affect only platforms where int is different
4019 than the definition of streamsize. However, since both functions are
4020 typically inline (they are on all known implementations), even on such
4021 platforms the change will not affect any user code unless it explicitly
4022 relies on the existing type of the functions (e.g., by taking their
4023 address). Such a possibility is IMO quite remote.
4027 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
4031 This is something of a nit, but I'm wondering if streamoff wouldn't be a
4032 better choice than streamsize. The argument to pbump and gbump MUST be
4033 signed. But the standard has this to say about streamsize
4034 (27.4.1/2/Footnote):
4038 [Footnote: streamsize is used in most places where ISO C would use
4039 size_t. Most of the uses of streamsize could use size_t, except for
4040 the strstreambuf constructors, which require negative values. It
4041 should probably be the signed type corresponding to size_t (which is
4042 what Posix.2 calls ssize_t). --- end footnote]
4046 This seems a little weak for the argument to pbump and gbump. Should we
4047 ever really get rid of strstream, this footnote might go with it, along
4048 with the reason to make streamsize signed.
4052 <p><b>Rationale:</b></p>
4053 <p>The LWG believes this change is too big for now. We may wish to
4054 reconsider this for a future revision of the standard. One
4055 possibility is overloading pbump, rather than changing the
4058 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
4066 <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
4067 <p><b>Section:</b> X [base], 24.4.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4068 <b>Submitter:</b> Robert Dick <b>Opened:</b> 2000-08-17 <b>Last modified:</b> 2010-10-29</p>
4069 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
4070 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4071 <p><b>Discussion:</b></p>
4073 According to the November 1997 Draft Standard, the results of deleting an
4074 object of a derived class through a pointer to an object of its base class are
4075 undefined if the base class has a non-virtual destructor. Therefore, it is
4076 potentially dangerous to publicly inherit from such base classes.
4081 The STL design encourages users to publicly inherit from a number of classes
4082 which do nothing but specify interfaces, and which contain non-virtual
4088 Wil Evers and William E. Kempf suggested this modification for functional
4093 <p><b>Proposed resolution:</b></p>
4095 When a base class in the standard library is useful only as an interface
4096 specifier, i.e., when an object of the class will never be directly
4097 instantiated, specify that the class contains a protected destructor. This
4098 will prevent deletion through a pointer to the base class without performance,
4099 or space penalties (on any implementation I'm aware of).
4103 As an example, replace...
4106 <pre> template <class Arg, class Result>
4107 struct unary_function {
4108 typedef Arg argument_type;
4109 typedef Result result_type;
4117 <pre> template <class Arg, class Result>
4118 struct unary_function {
4119 typedef Arg argument_type;
4120 typedef Result result_type;
4122 ~unary_function() {}
4127 Affected definitions:
4129 20.3.1 [lib.function.objects] -- unary_function, binary_function
4131 24.3.2 [lib.iterator.basic] -- iterator
4135 <p><b>Rationale:</b></p>
4137 The standard is clear as written; this is a request for change, not a
4138 defect in the strict sense. The LWG had several different objections
4139 to the proposed change. One is that it would prevent users from
4140 creating objects of type <tt>unary_function</tt> and
4141 <tt>binary_function</tt>. Doing so can sometimes be legitimate, if users
4142 want to pass temporaries as traits or tag types in generic code.
4150 <h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
4151 <p><b>Section:</b> D.9.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4152 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2010-10-29</p>
4153 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
4154 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4155 <p><b>Discussion:</b></p>
4157 It appears that the interaction of the strstreambuf members overflow()
4158 and seekoff() can lead to undefined behavior in cases where defined
4159 behavior could reasonably be expected. The following program
4160 demonstrates this behavior:
4163 <pre> #include <strstream>
4167 std::strstreambuf sb;
4170 sb.pubseekoff (-1, std::ios::end, std::ios::in);
4171 return !('c' == sb.sgetc ());
4176 D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(),
4177 which in turn sets all pointers to 0 in 27.5.2.1, p1.
4181 27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls
4182 overflow(traits::to_int_type(c)) if a write position isn't available (it
4183 isn't due to the above).
4187 D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
4188 least one write position available (i.e., it allows the function to make
4189 any positive number of write positions available).
4193 D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
4194 seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
4195 case. newoff is then epptr() - eback().
4199 D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
4200 gptr() == epptr() + off holds.
4204 If strstreambuf::overflow() made exactly one write position available
4205 then gptr() will be set to just before epptr(), and the program will
4206 return 0. Buf if the function made more than one write position
4207 available, epptr() and gptr() will both point past pptr() and the
4208 behavior of the program is undefined.
4212 <p><b>Proposed resolution:</b></p>
4215 <p>Change the last sentence of D.9.1 [depr.strstreambuf] paragraph 4 from</p>
4218 Otherwise, seeklow equals gbeg and seekhigh is either pend, if
4219 pend is not a null pointer, or gend.
4225 Otherwise, seeklow equals gbeg and seekhigh is either gend if
4226 0 == pptr(), or pbase() + max where max is the maximum value of
4227 pptr() - pbase() ever reached for this stream.
4231 pre-Copenhagen: Dietmar provided wording for proposed resolution.
4236 post-Copenhagen: Fixed a typo: proposed resolution said to fix
4243 <p><b>Rationale:</b></p>
4244 <p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
4245 means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
4246 the library working group does not wish to invest time nailing down
4247 corner cases in a deprecated feature.</p>
4254 <h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
4255 <p><b>Section:</b> 18.8 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4256 <b>Submitter:</b> J. Stephen Adamczyk <b>Opened:</b> 2000-10-10 <b>Last modified:</b> 2010-10-29</p>
4257 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
4258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4259 <p><b>Discussion:</b></p>
4261 One of our customers asks whether this is valid C++:
4264 <pre> #include <cstdarg>
4266 void bar(const char *, va_list);
4269 foo(const char *file, const char *, ...)
4279 The issue being whether it is valid to use cstdarg when the final
4280 parameter before the "..." is unnamed. cstdarg is, as far
4281 as I can tell, inherited verbatim from the C standard. and the
4282 definition there (7.8.1.1 in the ISO C89 standard) refers to "the
4283 identifier of the rightmost parameter". What happens when there
4284 is no such identifier?
4288 My personal opinion is that this should be allowed, but some tweak
4289 might be required in the C++ standard.
4293 <p><b>Rationale:</b></p>
4295 Not a defect, the C and C++ standards are clear. It is impossible to
4296 use varargs if the parameter immediately before "..." has no
4297 name, because that is the parameter that must be passed to va_start.
4298 The example given above is broken, because va_start is being passed
4299 the wrong parameter.
4303 There is no support for extending varargs to provide additional
4304 functionality beyond what's currently there. For reasons of C/C++
4305 compatibility, it is especially important not to make gratuitous
4306 changes in this part of the C++ standard. The C committee has already
4307 been requested not to touch this part of the C standard unless
4315 <h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
4316 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4317 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-07 <b>Last modified:</b> 2010-10-29</p>
4318 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
4319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4320 <p><b>Discussion:</b></p>
4322 In 20.1.5, paragraph 5, the standard says that "Implementors are
4323 encouraged to supply libraries that can accept allocators that
4324 encapsulate more general memory models and that support non-equal
4325 instances." This is intended as normative encouragement to
4326 standard library implementors. However, it is possible to interpret
4327 this sentence as applying to nonstandard third-party libraries.
4331 <p><b>Proposed resolution:</b></p>
4333 In 20.1.5, paragraph 5, change "Implementors" to
4334 "Implementors of the library described in this International
4339 <p><b>Rationale:</b></p>
4340 <p>The LWG believes the normative encouragement is already
4341 sufficiently clear, and that there are no important consequences
4342 even if it is misunderstood.</p>
4349 <h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
4350 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4351 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2010-10-29</p>
4352 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
4353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4354 <p><b>Discussion:</b></p>
4357 This came from an email from Steve Cleary to Fergus in reference to
4358 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
4359 this in Toronto and believes it should be a separate issue.
4363 Steve said: "We may want to state that the const/non-const iterators must have
4364 the same difference type, size_type, and category."
4369 I'm not sure if the above sentence should be true for all
4370 const and non-const iterators in a particular container, or if it means
4371 the container's iterator can't be compared with the container's
4372 const_iterator unless the above it true. I suspect the former.
4376 <p><b>Proposed resolution:</b></p>
4378 In <b>Section:</b> 23.2 [container.requirements],
4379 table 65, in the assertion/note pre/post condition for X::const_iterator,
4385 typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
4389 typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
4393 typeid(X::const_iterator::category) == typeid(X::iterator::category)
4398 <p><b>Rationale:</b></p>
4399 <p>Going through the types one by one: Iterators don't have a
4400 <tt>size_type</tt>. We already know that the difference types are
4401 identical, because the container requirements already say that the
4402 difference types of both X::iterator and X::const_iterator are both
4403 X::difference_type. The standard does not require that X::iterator
4404 and X::const_iterator have the same iterator category, but the LWG
4405 does not see this as a defect: it's possible to imagine cases in which
4406 it would be useful for the categories to be different.</p>
4408 <p>It may be desirable to require X::iterator and X::const_iterator to
4409 have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
4417 <h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
4418 <p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4419 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
4420 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
4421 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4422 <p><b>Discussion:</b></p>
4424 The Effects clause for ios_base::setf(fmtflags fmtfl) says
4425 "Sets fmtfl in flags()". What happens if the user first calls
4426 ios_base::scientific and then calls ios_base::fixed or vice-versa?
4427 This is an issue for all of the conflicting flags, i.e. ios_base::left
4428 and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
4432 I see three possible solutions:
4436 <li>Set ios_base::failbit whenever the user specifies a conflicting
4437 flag with one previously explicitly set. If the constructor is
4438 supposed to set ios_base::dec (see discussion below), then
4439 the user setting hex or oct format after construction will not
4441 <li>The last call to setf "wins", i.e. it clears any conflicting
4442 previous setting.</li>
4443 <li>All the flags that the user specifies are set, but when actually
4444 interpreting them, fixed always override scientific, right always
4445 overrides left, dec overrides hex which overrides oct.</li>
4449 Most existing implementations that I tried seem to conform to resolution #3,
4450 except that when using the iomanip manipulator hex or oct then that always
4451 overrides dec, but calling setf(ios_base::hex) doesn't.
4455 There is a sort of related issue, which is that although the ios_base
4456 constructor says that each ios_base member has an indeterminate value
4457 after construction, all the existing implementations I tried explicitly set
4462 <p><b>Proposed resolution:</b></p>
4465 <p><b>Rationale:</b></p>
4467 <tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
4468 are each multi-bit fields. It is possible to set multiple bits within
4469 each of those fields. (For example, <tt>dec</tt> and
4470 <tt>oct</tt>). These fields are used by locale facets. The LWG
4471 reviewed the way in which each of those three fields is used, and
4472 believes that in each case the behavior is well defined for any
4473 possible combination of bits. See for example Table 58, in 22.4.2.2.2 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that
4477 Users are advised to use manipulators, or else use the two-argument
4478 version of <tt>setf</tt>, to avoid unexpected behavior.
4486 <h3><a name="289"></a>289. <cmath> requirements missing C float and long double versions</h3>
4487 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4488 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
4489 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
4490 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4491 <p><b>Discussion:</b></p>
4493 In ISO/IEC 9899:1990 Programming Languages C we find the following
4494 concerning <math.h>:
4498 7.13.4 Mathematics <math.h>
4500 The names of all existing functions declared in the <math.h>
4501 header, suffixed with f or l, are reserved respectively for
4502 corresponding functions with float and long double arguments
4507 For example, <tt>float sinf(float)</tt>
4512 In the C99 standard, <math.h> must contain declarations
4513 for these functions.
4517 So, is it acceptable for an implementor to add these prototypes to the
4518 C++ versions of the math headers? Are they required?
4522 <p><b>Proposed resolution:</b></p>
4524 Add these Functions to Table 80, section 26.5 and to Table 99,
4528 <pre> acosf asinf atanf atan2f ceilf cosf coshf
4529 expf fabsf floorf fmodf frexpf ldexpf
4530 logf log10f modff powf sinf sinhf sqrtf
4532 acosl asinl atanl atan2l ceill cosl coshl
4533 expl fabsl floorl fmodl frexpl ldexpl
4534 logl log10l modfl powl sinl sinhl sqrtl
4539 There should probably be a note saying that these functions
4540 are optional and, if supplied, should match the description in
4541 the 1999 version of the C standard. In the next round
4542 of C++ standardization they can then become mandatory.
4546 <p><b>Rationale:</b></p>
4547 <p>The C90 standard, as amended, already permits (but does not
4548 require) these functions, and the C++ standard incorporates the
4549 C90 standard by reference. C99 is not an issue, because it is
4550 never referred to by the C++ standard.</p>
4557 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
4558 <p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4559 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2010-10-29</p>
4560 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
4561 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4562 <p><b>Discussion:</b></p>
4563 <p>The specification of the for_each algorithm does not have a
4564 "Requires" section, which means that there are no
4565 restrictions imposed on the function object whatsoever. In essence it
4566 means that I can provide any function object with arbitrary side
4567 effects and I can still expect a predictable result. In particular I
4568 can expect that the function object is applied exactly last - first
4569 times, which is promised in the "Complexity" section.
4572 <p>I don't see how any implementation can give such a guarantee
4573 without imposing requirements on the function object.
4576 <p>Just as an example: consider a function object that removes
4577 elements from the input sequence. In that case, what does the
4578 complexity guarantee (applies f exactly last - first times) mean?
4581 <p>One can argue that this is obviously a nonsensical application and
4582 a theoretical case, which unfortunately it isn't. I have seen
4583 programmers shooting themselves in the foot this way, and they did not
4584 understand that there are restrictions even if the description of the
4585 algorithm does not say so.
4587 <p><i>[Lillehammer: This is more general than for_each. We don't want
4588 the function object in transform invalidiating iterators
4589 either. There should be a note somewhere in clause 17 (17, not 25)
4590 saying that user code operating on a range may not invalidate
4591 iterators unless otherwise specified. Bill will provide wording.]</i></p>
4604 It was felt that the current description is adequate, and that there are
4605 limits to what the standard can reasonably say to prohibit perverse uses
4612 <p><b>Proposed resolution:</b></p>
4620 <h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
4621 <p><b>Section:</b> 25.3.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4622 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-04 <b>Last modified:</b> 2010-10-29</p>
4623 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
4624 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4625 <p><b>Discussion:</b></p>
4626 <p>This issue is related to issue 242. In case that the resolution
4627 proposed for issue 242 is accepted, we have have the following
4628 situation: The 4 numeric algorithms (accumulate and consorts) as well
4629 as transform would allow a certain category of side effects. The
4630 numeric algorithms specify that they invoke the functor "for
4631 every iterator i in the range [first, last) in order". transform,
4632 in contrast, would not give any guarantee regarding order of
4633 invocation of the functor, which means that the functor can be invoked
4634 in any arbitrary order.
4637 <p>Why would that be a problem? Consider an example: say the
4638 transformator that is a simple enumerator ( or more generally
4639 speaking, "is order-sensitive" ). Since a standard
4640 compliant implementation of transform is free to invoke the enumerator
4641 in no definite order, the result could be a garbled enumeration.
4642 Strictly speaking this is not a problem, but it is certainly at odds
4643 with the prevalent understanding of transform as an algorithms that
4644 assigns "a new _corresponding_ value" to the output
4648 <p>All implementations that I know of invoke the transformator in
4649 definite order, namely starting from first and proceeding to last -
4650 1. Unless there is an optimization conceivable that takes advantage of
4651 the indefinite order I would suggest to specify the order, because it
4652 eliminate the uncertainty that users would otherwise have regarding
4653 the order of execution of their potentially order-sensitive function
4658 <p><b>Proposed resolution:</b></p>
4659 <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
4661 -1- Effects: Assigns through every iterator i in the range [result,
4662 result + (last1 - first1)) a new corresponding
4663 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
4664 (i - result), *(first2 + (i - result))).
4668 -1- Effects: Computes values by invoking the operation op or binary_op
4669 for every iterator in the range [first1, last1) in order. Assigns through
4670 every iterator i in the range [result, result + (last1 - first1)) a new
4672 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
4673 (i - result), *(first2 + (i - result))).
4677 <p><b>Rationale:</b></p>
4678 <p>For Input Iterators an order is already guaranteed, because
4679 only one order is possible. If a user who passes a Forward
4680 Iterator to one of these algorithms really needs a specific
4681 order of execution, it's possible to achieve that effect by
4682 wrapping it in an Input Iterator adaptor.</p>
4689 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
4690 <p><b>Section:</b> 24.2.6 [bidirectional.iterators], 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
4691 <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22 <b>Last modified:</b> 2010-10-29</p>
4692 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
4693 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
4694 <p><b>Discussion:</b></p>
4696 In section 24.2.6 [bidirectional.iterators],
4697 Table 75 gives the return type of *r-- as convertible to T. This is
4698 not consistent with Table 74 which gives the return type of *r++ as
4699 T&. *r++ = t is valid while *r-- = t is invalid.
4703 In section 24.2.7 [random.access.iterators],
4704 Table 76 gives the return type of a[n] as convertible to T. This is
4705 not consistent with the semantics of *(a + n) which returns T& by
4706 Table 74. *(a + n) = t is valid while a[n] = t is invalid.
4710 Discussion from the Copenhagen meeting: the first part is
4711 uncontroversial. The second part, operator[] for Random Access
4712 Iterators, requires more thought. There are reasonable arguments on
4713 both sides. Return by value from operator[] enables some potentially
4714 useful iterators, e.g. a random access "iota iterator" (a.k.a
4715 "counting iterator" or "int iterator"). There isn't any obvious way
4716 to do this with return-by-reference, since the reference would be to a
4717 temporary. On the other hand, <tt>reverse_iterator</tt> takes an
4718 arbitrary Random Access Iterator as template argument, and its
4719 operator[] returns by reference. If we decided that the return type
4720 in Table 76 was correct, we would have to change
4721 <tt>reverse_iterator</tt>. This change would probably affect user
4726 History: the contradiction between <tt>reverse_iterator</tt> and the
4727 Random Access Iterator requirements has been present from an early
4728 stage. In both the STL proposal adopted by the committee
4729 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
4730 Stepanov and Lee), the Random Access Iterator requirements say that
4731 operator[]'s return value is "convertible to T". In N0527
4732 reverse_iterator's operator[] returns by value, but in HPL-95-11
4733 (R.1), and in the STL implementation that HP released to the public,
4734 reverse_iterator's operator[] returns by reference. In 1995, the
4735 standard was amended to reflect the contents of HPL-95-11 (R.1). The
4736 original intent for operator[] is unclear.
4740 In the long term it may be desirable to add more fine-grained
4741 iterator requirements, so that access method and traversal strategy
4742 can be decoupled. (See "Improved Iterator Categories and
4743 Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
4744 about issue 299 should keep this possibility in mind.
4747 <p>Further discussion: I propose a compromise between John Potter's
4748 resolution, which requires <tt>T&</tt> as the return type of
4749 <tt>a[n]</tt>, and the current wording, which requires convertible to
4750 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
4751 for the return type of the expression <tt>a[n]</tt>, but to also add
4752 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
4753 common case uses of random access iterators, while at the same time
4754 allowing iterators such as counting iterator and caching file
4755 iterators to remain random access iterators (iterators where the
4756 lifetime of the object returned by <tt>operator*()</tt> is tied to the
4757 lifetime of the iterator).
4761 Note that the compromise resolution necessitates a change to
4762 <tt>reverse_iterator</tt>. It would need to use a proxy to support
4767 Note also there is one kind of mutable random access iterator that
4768 will no longer meet the new requirements. Currently, iterators that
4769 return an r-value from <tt>operator[]</tt> meet the requirements for a
4770 mutable random access iterartor, even though the expression <tt>a[n] =
4771 t</tt> will only modify a temporary that goes away. With this proposed
4772 resolution, <tt>a[n] = t</tt> will be required to have the same
4773 operational semantics as <tt>*(a + n) = t</tt>.
4777 2009-07-28 Reopened by Alisdair. No longer solved by concepts.
4782 2009-09-18 Alisdair adds:
4788 Why can't we write through the reference returned from operator[] on a
4789 random access iterator?
4793 Recommended solution:
4797 In table Table 104 -- Random access iterator requirements, replace
4801 a[n] : convertible to <del><tt>const T &</tt></del>
4802 <ins><tt>T&</tt> if <tt>X</tt> is mutable, otherwise convertible to <tt>const T&</tt></ins>
4812 Leave Open. Alisdair to spearhead a paper on revivification.
4816 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
4822 <p><b>Rationale:</b></p>
4825 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
4829 <p><b>Proposed resolution:</b></p>
4832 In section 24.1.4 [lib.bidirectdional.iterators], change the return
4833 type in table 75 from "convertible to <tt>T</tt>" to
4838 In section 24.1.5 [lib.random.access.iterators], change the
4839 operational semantics for <tt>a[n]</tt> to " the r-value of
4840 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
4841 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
4842 with a return type of convertible to <tt>T</tt> and operational semantics of
4843 <tt>*(a + n) = t</tt>.
4846 <p><i>[Lillehammer: Real problem, but should be addressed as part of
4847 iterator redesign]</i></p>
4852 <p><b>Rationale:</b></p>
4860 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
4870 <h3><a name="302"></a>302. Need error indication from codecvt<>::do_length</h3>
4871 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4872 <b>Submitter:</b> Gregory Bumgardner <b>Opened:</b> 2001-01-25 <b>Last modified:</b> 2010-10-29</p>
4873 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
4874 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4875 <p><b>Discussion:</b></p>
4877 The effects of <tt>codecvt<>::do_length()</tt> are described in
4878 22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified
4879 in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt<>::do_length()</tt> must
4880 process the source data and update the <tt>stateT</tt> argument just
4881 as if the data had been processed by <tt>codecvt<>::in()</tt>.
4882 However, the standard does not specify how <tt>do_length()</tt> would
4883 report a translation failure, should the source sequence contain
4884 untranslatable or illegal character sequences.
4888 The other conversion methods return an "error" result value
4889 to indicate that an untranslatable character has been encountered, but
4890 <tt>do_length()</tt> already has a return value (the number of source
4891 characters that have been processed by the method).
4895 <p><b>Proposed resolution:</b></p>
4897 This issue cannot be resolved without modifying the interface. An exception
4898 cannot be used, as there would be no way to determine how many characters
4899 have been processed and the state object would be left in an indeterminate
4904 A source compatible solution involves adding a fifth argument to length()
4905 and do_length() that could be used to return position of the offending
4906 character sequence. This argument would have a default value that would
4907 allow it to be ignored:
4910 <pre> int length(stateT& state,
4911 const externT* from,
4912 const externT* from_end,
4914 const externT** from_next = 0);
4917 int do_length(stateT& state,
4918 const externT* from,
4919 const externT* from_end,
4921 const externT** from_next);
4925 Then an exception could be used to report any translation errors and
4926 the from_next argument, if used, could then be used to retrieve the
4927 location of the offending character sequence.
4931 <p><b>Rationale:</b></p>
4932 <p>The standard is already clear: the return value is the number of
4933 "valid complete characters". If it encounters an invalid sequence of
4934 external characters, it stops.</p>
4941 <h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
4942 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4943 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-02-05 <b>Last modified:</b> 2010-10-29</p>
4944 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
4945 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4946 <p><b>Discussion:</b></p>
4948 We all "know" that input iterators are allowed to produce
4949 values when dereferenced of which there is no other in-memory copy.
4953 But: Table 72, with a careful reading, seems to imply that this can only be
4954 the case if the value_type has no members (e.g. is a built-in type).
4957 <p>The problem occurs in the following entry:</p>
4959 <pre> a->m pre: (*a).m is well-defined
4960 Equivalent to (*a).m
4964 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
4965 type, but since <tt>operator->()</tt> must return a pointer for
4966 <tt>a->m</tt> to be well-formed, it needs something to return a
4967 pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
4968 buffered somewhere to make a legal input iterator.
4971 <p>I don't think this was intentional.</p>
4974 <p><b>Rationale:</b></p>
4975 <p>The current standard is clear and consistent. Input iterators that
4976 return rvalues are in fact implementable. They may in some cases
4977 require extra work, but it is still possible to define an operator->
4978 in such cases: it doesn't have to return a T*, but may return a
4979 proxy type. No change to the standard is justified.</p>
4986 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
4987 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4988 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-19 <b>Last modified:</b> 2010-10-29</p>
4989 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
4990 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4991 <p><b>Discussion:</b></p>
4993 The descriptions of the constructors of basic_istream<>::sentry
4994 (27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
4995 (27.7.2.4 [ostream::sentry]) do not explain what the functions do in
4996 case an exception is thrown while they execute. Some current
4997 implementations allow all exceptions to propagate, others catch them
4998 and set ios_base::badbit instead, still others catch some but let
5003 The text also mentions that the functions may call setstate(failbit)
5004 (without actually saying on what object, but presumably the stream
5005 argument is meant). That may have been fine for
5006 basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
5007 the function performs an input operation which may fail. However,
5008 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.7.1.1.3 [istream::sentry], p2 to
5009 clarify that the function should actually call setstate(failbit |
5010 eofbit), so the sentence in p3 is redundant or even somewhat
5015 The same sentence that appears in 27.7.2.4 [ostream::sentry], p3
5016 doesn't seem to be very meaningful for basic_istream<>::sentry
5017 which performs no input. It is actually rather misleading since it
5018 would appear to guide library implementers to calling
5019 setstate(failbit) when os.tie()->flush(), the only called function,
5020 throws an exception (typically, it's badbit that's set in response to
5024 <p><b>Additional comments from Martin, who isn't comfortable with the
5025 current proposed resolution</b> (see c++std-lib-11530)</p>
5028 The istream::sentry ctor says nothing about how the function
5029 deals with exemptions (27.6.1.1.2, p1 says that the class is
5030 responsible for doing "exception safe"(*) prefix and suffix
5031 operations but it doesn't explain what level of exception
5032 safety the class promises to provide). The mockup example
5033 of a "typical implementation of the sentry ctor" given in
5034 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
5035 exception handling, either. Since the ctor is not classified
5036 as a formatted or unformatted input function, the text in
5037 27.6.1.1, p1 through p4 does not apply. All this would seem
5038 to suggest that the sentry ctor should not catch or in any
5039 way handle exceptions thrown from any functions it may call.
5040 Thus, the typical implementation of an istream extractor may
5041 look something like [1].
5045 The problem with [1] is that while it correctly sets ios::badbit
5046 if an exception is thrown from one of the functions called from
5047 the sentry ctor, if the sentry ctor reaches EOF while extracting
5048 whitespace from a stream that has eofbit or failbit set in
5049 exceptions(), it will cause an ios::failure to be thrown, which
5050 will in turn cause the extractor to set ios::badbit.
5054 The only straightforward way to prevent this behavior is to
5055 move the definition of the sentry object in the extractor
5056 above the try block (as suggested by the example in 22.2.8,
5057 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
5058 But such an implementation will allow exceptions thrown from
5059 functions called from the ctor to freely propagate to the
5060 caller regardless of the setting of ios::badbit in the stream
5061 object's exceptions().
5065 So since neither [1] nor [2] behaves as expected, the only
5066 possible solution is to have the sentry ctor catch exceptions
5067 thrown from called functions, set badbit, and propagate those
5068 exceptions if badbit is also set in exceptions(). (Another
5069 solution exists that deals with both kinds of sentries, but
5070 the code is non-obvious and cumbersome -- see [3].)
5074 Please note that, as the issue points out, current libraries
5075 do not behave consistently, suggesting that implementors are
5076 not quite clear on the exception handling in istream::sentry,
5077 despite the fact that some LWG members might feel otherwise.
5078 (As documented by the parenthetical comment here:
5079 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
5083 Also please note that those LWG members who in Copenhagen
5084 felt that "a sentry's constructor should not catch exceptions,
5085 because sentries should only be used within (un)formatted input
5086 functions and that exception handling is the responsibility of
5087 those functions, not of the sentries," as noted here
5088 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
5089 would in effect be either arguing for the behavior described
5090 in [1] or for extractors implemented along the lines of [3].
5094 The original proposed resolution (Revision 25 of the issues
5095 list) clarifies the role of the sentry ctor WRT exception
5096 handling by making it clear that extractors (both library
5097 or user-defined) should be implemented along the lines of
5098 [2] (as opposed to [1]) and that no exception thrown from
5099 the callees should propagate out of either function unless
5100 badbit is also set in exceptions().
5104 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
5107 <pre>struct S { long i; };
5109 istream& operator>> (istream &strm, S &s)
5111 ios::iostate err = ios::goodbit;
5113 const istream::sentry guard (strm, false);
5115 use_facet<num_get<char> >(strm.getloc ())
5116 .get (istreambuf_iterator<char>(strm),
5117 istreambuf_iterator<char>(),
5124 strm.setstate (ios::badbit);
5134 strm.setstate (err);
5140 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
5143 <pre>istream& operator>> (istream &strm, S &s)
5145 istream::sentry guard (strm, false);
5147 ios::iostate err = ios::goodbit;
5149 use_facet<num_get<char> >(strm.getloc ())
5150 .get (istreambuf_iterator<char>(strm),
5151 istreambuf_iterator<char>(),
5157 strm.setstate (ios::badbit);
5167 strm.setstate (err);
5175 [3] Extractor that catches exceptions thrown from sentry
5176 but doesn't set badbit if the exception was thrown as a
5177 result of a call to strm.clear().
5181 <pre>istream& operator>> (istream &strm, S &s)
5183 const ios::iostate state = strm.rdstate ();
5184 const ios::iostate except = strm.exceptions ();
5185 ios::iostate err = std::ios::goodbit;
5188 const istream::sentry guard (strm, false);
5191 use_facet<num_get<char> >(strm.getloc ())
5192 .get (istreambuf_iterator<char>(strm),
5193 istreambuf_iterator<char>(),
5198 if (thrown && state & except)
5201 strm.setstate (ios::badbit);
5211 strm.setstate (err);
5219 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
5223 [Pre-Portland] A relevant newsgroup post:
5227 The current proposed resolution of issue #309
5228 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
5229 unacceptable. I write commerical software and coding around this
5230 makes my code ugly, non-intuitive, and requires comments referring
5231 people to this very issue. Following is the full explanation of my
5235 In the course of writing software for commercial use, I constructed
5236 std::ifstream's based on user-supplied pathnames on typical POSIX
5240 It was expected that some files that opened successfully might not read
5241 successfully -- such as a pathname which actually refered to a
5242 directory. Intuitively, I expected the streambuffer underflow() code
5243 to throw an exception in this situation, and recent implementations of
5244 libstdc++'s basic_filebuf do just that (as well as many of my own
5248 I also intuitively expected that the istream code would convert these
5249 exceptions to the "badbit' set on the stream object, because I had not
5250 requested exceptions. I refer to 27.6.1.1. P4.
5253 However, this was not the case on at least two implementations -- if
5254 the first thing I did with an istream was call operator>>( T& ) for T
5255 among the basic arithmetic types and std::string. Looking further I
5256 found that the sentry's constructor was invoking the exception when it
5257 pre-scanned for whitespace, and the extractor function (operator>>())
5258 was not catching exceptions in this situation.
5261 So, I was in a situation where setting 'noskipws' would change the
5262 istream's behavior even though no characters (whitespace or not) could
5263 ever be successfully read.
5266 Also, calling .peek() on the istream before calling the extractor()
5267 changed the behavior (.peek() had the effect of setting the badbit
5271 I found this all to be so inconsistent and inconvenient for me and my
5272 code design, that I filed a bugzilla entry for libstdc++. I was then
5273 told that the bug cannot be fixed until issue #309 is resolved by the
5287 See the rationale in the issue. Paolo, who requested that the issue be
5288 reopened, agreed with the rationale.
5294 <p><b>Proposed resolution:</b></p>
5297 <p><b>Rationale:</b></p>
5298 <p>The LWG agrees there is minor variation between implementations,
5299 but believes that it doesn't matter. This is a rarely used corner
5300 case. There is no evidence that this has any commercial importance
5301 or that it causes actual portability problems for customers trying
5302 to write code that runs on multiple implementations.</p>
5309 <h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
5310 <p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5311 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2001-04-03 <b>Last modified:</b> 2010-10-29</p>
5312 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
5313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5314 <p><b>Discussion:</b></p>
5316 According to section 18.7.3.3 of the standard, std::terminate() is
5317 supposed to call the terminate_handler in effect immediately after
5318 evaluating the throw expression.
5322 Question: what if the terminate_handler in effect is itself
5328 <pre> #include <exception>
5331 std::set_terminate(std::terminate);
5338 Is the implementation allowed to go into an infinite loop?
5342 I think the same issue applies to std::set_unexpected.
5346 <p><b>Proposed resolution:</b></p>
5349 <p><b>Rationale:</b></p>
5350 <p>Infinite recursion is to be expected: users who set the terminate
5351 handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
5359 <h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
5360 <p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5361 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-04-11 <b>Last modified:</b> 2010-10-29</p>
5362 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
5363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5364 <p><b>Discussion:</b></p>
5367 The standard appears to contradict itself about whether the stack is
5368 unwound when the implementation calls terminate().
5371 <p>From 18.7.3.3p2:</p>
5373 Calls the terminate_handler function in effect immediately
5374 after evaluating the throw-expression (lib.terminate.handler),
5375 if called by the implementation [...]
5378 <p>So the stack is guaranteed not to be unwound.</p>
5380 <p>But from 15.3p9:</p>
5382 [...]whether or not the stack is unwound before this call
5383 to terminate() is implementation-defined (except.terminate).
5387 And 15.5.1 actually defines that in most cases the stack is unwound.
5391 <p><b>Proposed resolution:</b></p>
5394 <p><b>Rationale:</b></p>
5395 <p>There is definitely no contradiction between the core and library
5396 clauses; nothing in the core clauses says that stack unwinding happens
5397 after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything
5398 about when terminate() is called; it merely specifies which
5399 <tt>terminate_handler</tt> is used.</p>
5406 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
5407 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5408 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-04 <b>Last modified:</b> 2010-10-29</p>
5409 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
5410 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5411 <p><b>Discussion:</b></p>
5412 <p>Currently the standard mandates the following overloads of
5415 <pre> abs(long), abs(int) in <cstdlib>
5417 abs(float), abs(double), abs(long double) in <cmath>
5419 template<class T> T abs(const complex<T>&) in <complex>
5421 template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
5425 The problem is that having only some overloads visible of a function
5426 that works on "implicitly inter-convertible" types is dangerous in
5427 practice. The headers that get included at any point in a translation
5428 unit can change unpredictably during program
5429 development/maintenance. The wrong overload might be unintentionally
5434 Currently, there is nothing that mandates the simultaneous visibility
5435 of these overloads. Indeed, some vendors have begun fastidiously
5436 reducing dependencies among their (public) headers as a QOI issue: it
5437 helps people to write portable code by refusing to compile unless all
5438 the correct headers are #included.
5441 <p>The same issue may exist for other functions in the library.</p>
5443 <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
5444 and int_max_abs.</p>
5446 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>.</p>
5454 The situation is not sufficiently severe to warrant a change.
5460 <p><b>Rationale:</b></p>
5461 <p>The programs that could potentially be broken by this situation are
5462 already fragile, and somewhat contrived: For example, a user-defined
5463 class that has conversion overloads both to <tt>long</tt> and
5464 to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then
5465 <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
5466 included <cstdlib>, the <tt>float</tt> version if the user
5467 included <cmath>, and would be diagnosed as ambiguous at
5468 compile time if the user included both headers. The LWG couldn't
5469 find an example of a program whose meaning would be changed (as
5470 opposed to changing it from well-formed to ill-formed) simply by
5471 adding another standard header.</p>
5473 <p>Since the harm seems minimal, and there don't seem to be any simple
5474 and noninvasive solutions, this is being closed as NAD. It is
5475 marked as "Future" for two reasons. First, it might be useful to
5476 define an <tt><all></tt> header that would include all
5477 Standard Library headers. Second, we should at least make sure that
5478 future library extensions don't make this problem worse.</p>
5485 <h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
5486 <p><b>Section:</b> 22.4.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5487 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-05 <b>Last modified:</b> 2010-10-29</p>
5488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5489 <p><b>Discussion:</b></p>
5490 <p>The definition of the moneypunct facet contains the typedefs char_type
5491 and string_type. Only one of these names, string_type, is defined in
5492 the derived facet, moneypunct_byname.</p>
5495 <p><b>Proposed resolution:</b></p>
5496 <p>For consistency with the numpunct facet, add a typedef for
5497 char_type to the definition of the moneypunct_byname facet in
5498 22.4.6.4 [locale.moneypunct.byname].</p>
5501 <p><b>Rationale:</b></p>
5502 <p>The absence of the typedef is irrelevant. Users can still access
5503 the typedef, because it is inherited from the base class.</p>
5510 <h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
5511 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5512 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-15 <b>Last modified:</b> 2010-10-29</p>
5513 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
5514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5515 <p><b>Discussion:</b></p>
5517 The "exposition only" value of the std::locale::none constant shown in
5518 the definition of class locale is misleading in that it on many
5519 systems conflicts with the value assigned to one if the LC_XXX
5520 constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
5521 on Linux and SunOS). This causes incorrect behavior when such a
5522 constant is passed to one of the locale member functions that accept a
5523 locale::category argument and interpret it as either the C LC_XXX
5524 constant or a bitmap of locale::category values. At least three major
5525 implementations adopt the suggested value without a change and
5526 consequently suffer from this problem.
5530 For instance, the following code will (presumably) incorrectly copy facets
5531 belonging to the collate category from the German locale on AIX:
5534 <pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none);
5538 <p><b>Rationale:</b></p>
5539 <p>The LWG agrees that it may be difficult to implement locale member
5540 functions in such a way that they can take either <tt>category</tt>
5541 arguments or the LC_ constants defined in <cctype>. In light of
5542 this requirement (22.3.1.1.1 [locale.category], paragraph 2), and in light
5543 of the requirement in the preceding paragraph that it is possible to
5544 combine <tt>category</tt> bitmask elements with bitwise operations,
5545 defining the <tt>category</tt> elements is delicate,
5546 particularly if an implementor is constrained to work with a
5547 preexisting C library. (Just using the existing LC_ constants would
5548 not work in general.) There's no set of "exposition only" values that
5549 could give library implementors proper guidance in such a delicate
5550 matter. The non-normative example we're giving is no worse than
5551 any other choice would be.</p>
5553 <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
5560 <h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos< T > </h3>
5561 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5562 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2010-10-29</p>
5563 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
5564 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5565 <p><b>Discussion:</b></p>
5567 Increment and decrement operators are missing from
5568 Table 88 -- Position type requirements in 27.5.3 [fpos].
5572 <p><b>Proposed resolution:</b></p>
5574 Table 88 (section 27.4.3) -- Position type requirements
5575 be updated to include increment and decrement operators.
5578 <pre>expression return type operational note
5580 ++p fpos& p += O(1)
5581 p++ fpos { P tmp = p;
5584 --p fpos& p -= O(1)
5585 p-- fpos { P tmp = p;
5592 <p><b>Rationale:</b></p>
5593 <p>The LWG believes this is a request for extension, not a defect
5594 report. Additionally, nobody saw a clear need for this extension;
5595 <tt>fpos</tt> is used only in very limited ways.</p>
5602 <h3><a name="342"></a>342. seek and eofbit</h3>
5603 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5604 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2010-10-29</p>
5605 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
5606 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5607 <p><b>Discussion:</b></p>
5608 <p>I think we have a defect.</p>
5610 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
5611 description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks
5615 Behaves as an unformatted input function (as described in 27.6.1.3,
5616 paragraph 1), except that it does not count the number of characters
5617 extracted and does not affect the value returned by subsequent calls to
5618 gcount(). After constructing a sentry object, if fail() != true,
5619 executes rdbuf()->pubseekpos( pos).
5622 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
5623 27.6.1.3, paragraph 1 looks like:</p>
5626 Each unformatted input function begins execution by constructing an
5627 object of class sentry with the default argument noskipws (second)
5628 argument true. If the sentry object returns true, when converted to a
5629 value of type bool, the function endeavors to obtain the requested
5630 input. Otherwise, if the sentry constructor exits by throwing an
5631 exception or if the sentry object returns false, when converted to a
5632 value of type bool, the function returns without attempting to obtain
5633 any input. In either case the number of extracted characters is set to
5634 0; unformatted input functions taking a character array of non-zero
5635 size as an argument shall also store a null character (using charT())
5636 in the first location of the array. If an exception is thrown during
5637 input then ios::badbit is turned on in *this'ss error state. If
5638 (exception()&badbit)!= 0 then the exception is rethrown. It also counts
5639 the number of characters extracted. If no exception has been thrown it
5640 ends by storing the count in a member object and returning the value
5641 specified. In any event the sentry object is destroyed before leaving
5642 the unformatted input function.
5645 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
5648 If, after any preparation is completed, is.good() is true, ok_ != false
5649 otherwise, ok_ == false.
5653 So although the seekg paragraph says that the operation proceeds if
5654 !fail(), the behavior of unformatted functions says the operation
5655 proceeds only if good(). The two statements are contradictory when only
5656 eofbit is set. I don't think the current text is clear which condition
5657 should be respected.
5660 <p><b>Further discussion from Redmond:</b></p>
5662 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
5663 "unformatted". That makes specific claims about sentry that
5664 aren't quite appropriate for seeking, which has less fragile failure
5665 modes than actual input. If we do really mean that it's unformatted
5666 input, it should behave the same way as other unformatted input. On
5667 the other hand, "principle of least surprise" is that seeking from EOF
5671 Pre-Berlin: Paolo points out several problems with the proposed resolution in
5676 <li>It should apply to both overloads of seekg.</li>
5677 <li>tellg has similar issues, except that it should not call clear().</li>
5678 <li>The point about clear() seems to apply to seekp().</li>
5679 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>
5681 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
5682 you can never seek away from the end of stream.</li>
5692 Moved to NAD. Will reopen if proposed resolution is supplied.
5698 <p><b>Proposed resolution:</b></p>
5700 <p>Change 27.7.1.3 [istream.unformatted] to:</p>
5702 Behaves as an unformatted input function (as described in 27.6.1.3,
5703 paragraph 1), except that it does not count the number of characters
5704 extracted, does not affect the value returned by subsequent calls to
5705 gcount(), and does not examine the value returned by the sentry
5706 object. After constructing a sentry object, if <tt>fail() !=
5707 true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In
5708 case of success, the function calls clear().
5709 In case of failure, the function calls <tt>setstate(failbit)</tt>
5710 (which may throw <tt>ios_base::failure</tt>).
5713 <p><i>[Lillehammer: Matt provided wording.]</i></p>
5718 <p><b>Rationale:</b></p>
5719 <p>In C, fseek does clear EOF. This is probably what most users would
5720 expect. We agree that having eofbit set should not deter a seek,
5721 and that a successful seek should clear eofbit. Note
5722 that <tt>fail()</tt> is true only if <tt>failbit</tt>
5723 or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
5724 than <tt>good()</tt>, satisfies this goal.</p>
5731 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
5732 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5733 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2010-10-29</p>
5734 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
5735 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
5736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5737 <p><b>Discussion:</b></p>
5739 The synopses of the C++ library headers clearly show which names are
5740 required to be defined in each header. Since in order to implement the
5741 classes and templates defined in these headers declarations of other
5742 templates (but not necessarily their definitions) are typically
5743 necessary the standard in 17.4.4, p1 permits library implementers to
5744 include any headers needed to implement the definitions in each header.
5748 For instance, although it is not explicitly specified in the synopsis of
5749 <string>, at the point of definition of the std::basic_string template
5750 the declaration of the std::allocator template must be in scope. All
5751 current implementations simply include <memory> from within <string>,
5752 either directly or indirectly, to bring the declaration of
5753 std::allocator into scope.
5757 Additionally, however, some implementation also include <istream> and
5758 <ostream> at the top of <string> to bring the declarations of
5759 std::basic_istream and std::basic_ostream into scope (which are needed
5760 in order to implement the string inserter and extractor operators
5761 (21.3.7.9 [lib.string.io])). Other implementations only include
5762 <iosfwd>, since strictly speaking, only the declarations and not the
5763 full definitions are necessary.
5767 Obviously, it is possible to implement <string> without actually
5768 providing the full definitions of all the templates std::basic_string
5769 uses (std::allocator, std::basic_istream, and std::basic_ostream).
5770 Furthermore, not only is it possible, doing so is likely to have a
5771 positive effect on compile-time efficiency.
5775 But while it may seem perfectly reasonable to expect a program that uses
5776 the std::basic_string insertion and extraction operators to also
5777 explicitly include <istream> or <ostream>, respectively, it doesn't seem
5778 reasonable to also expect it to explicitly include <memory>. Since
5779 what's reasonable and what isn't is highly subjective one would expect
5780 the standard to specify what can and what cannot be assumed.
5781 Unfortunately, that isn't the case.
5784 <p>The examples below demonstrate the issue.</p>
5788 <p>It is not clear whether the following program is complete:</p>
5790 <pre>#include <string>
5792 extern std::basic_ostream<char> &strm;
5795 strm << std::string ("Hello, World!\n");
5799 <p>or whether one must explicitly include <memory> or
5800 <ostream> (or both) in addition to <string> in order for
5801 the program to compile.</p>
5806 <p>Similarly, it is unclear whether the following program is complete:</p>
5808 <pre>#include <istream>
5810 extern std::basic_iostream<char> &strm;
5813 strm << "Hello, World!\n";
5818 or whether one needs to explicitly include <ostream>, and
5819 perhaps even other headers containing the definitions of other
5820 required templates:</p>
5822 <pre>#include <ios>
5823 #include <istream>
5824 #include <ostream>
5825 #include <streambuf>
5827 extern std::basic_iostream<char> &strm;
5830 strm << "Hello, World!\n";
5836 <p>Likewise, it seems unclear whether the program below is complete:</p>
5837 <pre>#include <iterator>
5839 bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b)
5847 <p>or whether one should be required to include <istream>.</p>
5849 <p>There are many more examples that demonstrate this lack of a
5850 requirement. I believe that in a good number of cases it would be
5851 unreasonable to require that a program explicitly include all the
5852 headers necessary for a particular template to be specialized, but I
5853 think that there are cases such as some of those above where it would
5854 be desirable to allow implementations to include only as much as
5855 necessary and not more.</p>
5863 Position taken in prior reviews is that the idea of a table of header
5864 dependencies is a good one. Our view is that a full paper is needed to
5865 do justice to this, and we've made that recommendation to the issue
5875 NAD. Handled by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.
5880 <p><b>Proposed resolution:</b></p>
5882 For every C++ library header, supply a minimum set of other C++ library
5883 headers that are required to be included by that header. The proposed
5884 list is below (C++ headers for C Library Facilities, table 12 in
5885 17.4.1.2, p3, are omitted):
5888 <pre>+------------+--------------------+
5889 | C++ header |required to include |
5890 +============+====================+
5891 |<algorithm> | |
5892 +------------+--------------------+
5894 +------------+--------------------+
5895 |<complex> | |
5896 +------------+--------------------+
5897 |<deque> |<memory> |
5898 +------------+--------------------+
5899 |<exception> | |
5900 +------------+--------------------+
5901 |<fstream> |<ios> |
5902 +------------+--------------------+
5903 |<functional>| |
5904 +------------+--------------------+
5905 |<iomanip> |<ios> |
5906 +------------+--------------------+
5907 |<ios> |<streambuf> |
5908 +------------+--------------------+
5910 +------------+--------------------+
5911 |<iostream> |<istream>, <ostream>|
5912 +------------+--------------------+
5913 |<istream> |<ios> |
5914 +------------+--------------------+
5915 |<iterator> | |
5916 +------------+--------------------+
5918 +------------+--------------------+
5919 |<list> |<memory> |
5920 +------------+--------------------+
5922 +------------+--------------------+
5923 |<map> |<memory> |
5924 +------------+--------------------+
5926 +------------+--------------------+
5927 |<new> |<exception> |
5928 +------------+--------------------+
5929 |<numeric> | |
5930 +------------+--------------------+
5931 |<ostream> |<ios> |
5932 +------------+--------------------+
5933 |<queue> |<deque> |
5934 +------------+--------------------+
5935 |<set> |<memory> |
5936 +------------+--------------------+
5937 |<sstream> |<ios>, <string> |
5938 +------------+--------------------+
5939 |<stack> |<deque> |
5940 +------------+--------------------+
5941 |<stdexcept> | |
5942 +------------+--------------------+
5943 |<streambuf> |<ios> |
5944 +------------+--------------------+
5945 |<string> |<memory> |
5946 +------------+--------------------+
5947 |<strstream> | |
5948 +------------+--------------------+
5949 |<typeinfo> |<exception> |
5950 +------------+--------------------+
5951 |<utility> | |
5952 +------------+--------------------+
5953 |<valarray> | |
5954 +------------+--------------------+
5955 |<vector> |<memory> |
5956 +------------+--------------------+
5960 <p><b>Rationale:</b></p>
5961 <p>The portability problem is real. A program that works correctly on
5962 one implementation might fail on another, because of different header
5963 dependencies. This problem was understood before the standard was
5964 completed, and it was a conscious design choice.</p>
5965 <p>One possible way to deal with this, as a library extension, would
5966 be an <all> header.</p>
5969 Hinnant: It's time we dealt with this issue for C++0X. Reopened.
5979 <h3><a name="344"></a>344. grouping + showbase</h3>
5980 <p><b>Section:</b> 22.4.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5981 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-13 <b>Last modified:</b> 2010-10-29</p>
5982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5983 <p><b>Discussion:</b></p>
5985 When both grouping and showbase are active and the basefield is octal,
5986 does the leading 0 participate in the grouping or not? For example,
5987 should one format as: 0,123,456 or 0123,456?
5990 An analogy can be drawn with hexadecimal. It appears that 0x123,456 is
5991 preferred over 0x,123,456. However, this analogy is not universally
5992 accepted to apply to the octal base. The standard is not clear on how
5993 to format (or parse) in this manner.
5996 <p><b>Proposed resolution:</b></p>
5998 Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
6002 The leading hexadecimal base specifier "0x" does not participate in
6003 grouping. The leading '0' octal base specifier may participate in
6004 grouping. It is unspecified if the leading '0' participates in
6005 formatting octal numbers. In parsing octal numbers, the implementation
6006 is encouraged to accept both the leading '0' participating in the
6007 grouping, and not participating (e.g. 0123,456 or 0,123,456).
6010 <p><b>Rationale:</b></p>
6012 The current behavior may be unspecified, but it's not clear that it
6013 matters. This is an obscure corner case, since grouping is usually
6014 intended for the benefit of humans and oct/hex prefixes are usually
6015 intended for the benefit of machines. There is not a strong enough
6016 consensus in the LWG for action.
6023 <h3><a name="348"></a>348. Minor issue with std::pair operator<</h3>
6024 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6025 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2010-10-29</p>
6026 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
6027 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6028 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p>
6029 <p><b>Discussion:</b></p>
6033 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
6034 operator< on any pair type which contains a pointer.
6038 <p><b>Proposed resolution:</b></p>
6039 <p>In 20.3.5 [pairs] paragraph 6, replace:</p>
6040 <pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second <
6044 <pre> Returns: std::less<T1>()( x.first, y.first ) ||
6045 (!std::less<T1>()( y.first, x.first) &&
6046 std::less<T2>()( x.second, y.second ) )
6051 <p><b>Rationale:</b></p>
6052 <p>This is an instance of a much more general problem. If we want
6053 operator< to translate to std::less for pairs of pointers, where
6054 do we draw the line? The same issue applies to individual
6055 pointers, smart pointer wrappers, std::vector<T*>, and so
6058 <p>Andy Koenig suggests that the real issue here is that we aren't
6059 distinguishing adequately between two different orderings, a
6060 "useful ordering" and a "canonical ordering" that's used just
6061 because we sometimes need <i>some</i> ordering without caring much
6062 which ordering it is. Another example of the later is typeinfo's
6063 <tt>before</tt>.</p>
6071 <h3><a name="350"></a>350. allocator<>::address</h3>
6072 <p><b>Section:</b> 20.9.5.1 [allocator.members], 20.2.5 [allocator.requirements], 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6073 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2001-10-25 <b>Last modified:</b> 2010-10-29</p>
6074 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
6075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6076 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
6077 <p><b>Discussion:</b></p>
6078 <p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
6079 verbatim from -9007.</p>
6082 The core language feature allowing definition of operator&() applied
6083 to any non-builtin type makes that operator often unsafe to use in
6084 implementing libraries, including the Standard Library. The result
6085 is that many library facilities fail for legal user code, such as
6087 <pre> class A { private: A* operator&(); };
6088 std::vector<A> aa;
6091 B* operator&(B&) { return 0; }
6092 std::vector<B> ba;
6096 In particular, the requirements table for Allocator (Table 32) specifies
6097 no semantics at all for member address(), and allocator<>::address is
6098 defined in terms of unadorned operator &.
6103 <p><b>Proposed resolution:</b></p>
6105 In 20.6.1.1, Change the definition of allocator<>::address from:</p>
6113 Returns: The value that the built in operator&(x) would return if not
6118 In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
6119 a.address(s) lines, respectively:
6122 <pre> allocator<T>::address(r)
6123 allocator<T>::address(s)
6126 <p>In addition, in clause 17.4.1.1, add a statement:</p>
6129 The Standard Library does not apply operator& to any type for which
6130 operator& may be overloaded.
6135 <p><b>Rationale:</b></p>
6136 <p>The LWG believes both examples are ill-formed. The contained type
6137 is required to be CopyConstructible (20.2.1 [utility.arg.requirements]), and that
6138 includes the requirement that &t return the usual types and
6139 values. Since allocators are intended to be used in conjunction with
6140 containers, and since the CopyConstructible requirements appear to
6141 have been written to deal with the concerns of this issue, the LWG
6142 feels it is NAD unless someone can come up with a well-formed example
6143 exhibiting a problem.</p>
6145 <p>It may well be that the CopyConstructible requirements are too
6146 restrictive and that either the container requirements or the
6147 CopyConstructive requirements should be relaxed, but that's a far
6148 larger issue. Marking this issue as "future" as a pointer to that
6156 <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
6157 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
6158 <b>Submitter:</b> Dale Riley <b>Opened:</b> 2001-11-12 <b>Last modified:</b> 2010-10-29</p>
6159 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
6160 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
6161 <p><b>Discussion:</b></p>
6163 In 20.8 [function.objects] the header <functional> synopsis declares
6164 the unary_negate and binary_negate function objects as struct.
6165 However in 20.8.9 [negators] the unary_negate and binary_negate
6166 function objects are defined as class. Given the context, they are
6167 not "basic function objects" like negate, so this is either a typo or
6168 an editorial oversight.
6171 <p><i>[Taken from comp.std.c++]</i></p>
6175 <p><b>Proposed resolution:</b></p>
6176 <p>Change the synopsis to reflect the useage in 20.8.9 [negators]</p>
6178 <p><i>[Curaçao: Since the language permits "struct", the LWG
6179 views this as NAD. They suggest, however, that the Project Editor
6180 might wish to make the change as editorial.]</i></p>
6189 <h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
6190 <p><b>Section:</b> 22.4.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6191 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2010-10-29</p>
6192 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
6193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6194 <p><b>Discussion:</b></p>
6196 <p>What should the following program print?</p>
6198 <pre> #include <locale>
6199 #include <iostream>
6201 class my_ctype : public std::ctype<char>
6203 typedef std::ctype<char> base;
6205 my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
6207 std::copy(base::classic_table(), base::classic_table() + base::table_size,
6209 my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
6212 mask my_table[base::table_size];
6218 std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " "
6219 << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl;
6223 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
6225 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On
6226 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
6229 I believe that both implementations are legal, and the standard does not
6230 give enough guidance for users to be able to use std::ctype's
6231 protected interface portably.</p>
6234 The above program assumes that ctype_base::mask enumerators like
6235 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
6236 say that a character is both a space and a printing character is to or
6237 those two enumerators together. This is suggested by the "exposition
6238 only" values in 22.4.1 [category.ctype], but it is nowhere specified in
6239 normative text. An alternative interpretation is that the more
6240 specific categories subsume the less specific. The above program
6241 gives the results it does on the Microsoft compiler because, on that
6242 compiler, <tt>print</tt> has all the bits set for each specific
6243 printing character class.
6246 <p>From the point of view of std::ctype's public interface, there's no
6247 important difference between these two techniques. From the point of
6248 view of the protected interface, there is. If I'm defining a facet
6249 that inherits from std::ctype<char>, I'm the one who defines the
6250 value that table()['a'] returns. I need to know what combination of
6251 mask values I should use. This isn't so very esoteric: it's exactly
6252 why std::ctype has a protected interface. If we care about users
6253 being able to write their own ctype facets, we have to give them a
6254 portable way to do it.
6258 Related reflector messages:
6259 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
6263 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The
6264 proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
6265 ctype_base::mask must be a bitmask type. It does not say that the
6266 ctype_base::mask elements are bitmask elements, so it doesn't
6267 directly affect this issue.</p>
6269 <p>More comments from Benjamin Kosnik, who believes that
6270 that C99 compatibility essentially requires what we're
6271 calling option 1 below.</p>
6274 <pre>I think the C99 standard is clear, that isspace -> !isalpha.
6277 #include <locale>
6278 #include <iostream>
6280 class my_ctype : public std::ctype<char>
6283 typedef std::ctype<char> base;
6284 mask my_table[base::table_size];
6287 my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
6289 std::copy(base::classic_table(), base::classic_table() + base::table_size,
6291 mask both = base::print | base::space;
6292 my_table[static_cast<mask>('_')] = both;
6298 using namespace std;
6300 cout << "isspace: " << ct.is(ctype_base::space, '_') << endl;
6301 cout << "isprint: " << ct.is(ctype_base::print, '_') << endl;
6303 // ISO C99, isalpha iff upper | lower set, and !space.
6305 // -> looks like g++ behavior is correct.
6306 // 356 -> bitmask elements are required for ctype_base
6307 // 339 -> bitmask type required for mask
6308 cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl;
6315 <p><b>Proposed resolution:</b></p>
6316 <p>Informally, we have three choices:</p>
6318 <li>Require that the enumerators are disjoint (except for alnum and
6320 <li>Require that the enumerators are not disjoint, and specify which
6321 of them subsume which others. (e.g. mandate that lower includes alpha
6323 <li>Explicitly leave this unspecified, which the result that the above
6324 program is not portable.</li>
6327 <p>Either of the first two options is just as good from the standpoint
6328 of portability. Either one will require some implementations to
6332 <p><b>Rationale:</b></p>
6333 <p>The LWG agrees that this is a real ambiguity, and that both
6334 interpretations are conforming under the existing standard. However,
6335 there's no evidence that it's causing problems for real users. Users
6336 who want to define ctype facets portably can test the ctype_base masks
6337 to see which interpretation is being used.</p>
6344 <h3><a name="357"></a>357. <cmath> float functions cannot return HUGE_VAL</h3>
6345 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
6346 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-02-26 <b>Last modified:</b> 2010-10-29</p>
6347 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
6348 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
6349 <p><b>Discussion:</b></p>
6351 The float versions of the math functions have no meaningful value to return
6352 for a range error. The long double versions have a value they can return,
6353 but it isn't necessarily the most reasonable value.
6357 Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
6358 double overloaded versions of these functions, with the same semantics,"
6359 referring to the math functions from the C90 standard.
6363 The C90 standard, in section 7.5.1, paragraph 3, says that functions return
6364 "the value of the macro HUGE_VAL" when they encounter a range error.
6365 Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
6366 positive double expression, not necessarily representable as a float."
6370 Therefore, the float versions of the math functions have no way to
6371 signal a range error. <i>[Curaçao: The LWG notes that this isn't
6372 strictly correct, since errno is set.]</i> The semantics require that they
6373 return HUGE_VAL, but they cannot because HUGE_VAL might not be
6374 representable as a float.
6378 The problem with long double functions is less severe because HUGE_VAL is
6379 representable as a long double. On the other hand, it might not be a "huge"
6380 long double value, and might fall well within the range of normal return
6381 values for a long double function. Therefore, it does not make sense for a
6382 long double function to return a double (HUGE_VAL) for a range error.
6386 <p><b>Proposed resolution:</b></p>
6387 <p>Curaçao: C99 was faced with a similar problem, which they fixed by
6388 adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
6390 <p>C++ must also fix, but it should be done in the context of the
6391 general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
6392 felt the resolution should be NAD, FUTURE, but the issue is being held
6393 open for one more meeting to ensure LWG members not present during the
6394 discussion concur.</p>
6397 <p><b>Rationale:</b></p>
6398 <p>Will be fixed as part of more general work in the TR.</p>
6405 <h3><a name="361"></a>361. num_get<>::do_get (..., void*&) checks grouping</h3>
6406 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6407 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
6408 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
6409 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6410 <p><b>Discussion:</b></p>
6412 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
6413 for integral types (issue 282 suggests that this should be done for
6414 all arithmetic types).
6418 22.2.2.1.2, p12 requires that grouping be checked for all extractors
6419 including that for <tt>void*</tt>.
6423 I don't think that's right. <tt>void*</tt> values should not be checked for
6424 grouping, should they? (Although if they should, then <tt>num_put</tt> needs
6425 to write them out, otherwise their extraction will fail.)
6429 <p><b>Proposed resolution:</b></p>
6431 Change the first sentence of 22.2.2.2.2, p12 from
6434 Digit grouping is checked. That is, the positions of discarded
6435 separators is examined for consistency with
6436 use_facet<numpunct<charT> >(loc).grouping().
6437 If they are not consistent then ios_base::failbit is assigned
6443 Except for conversions to void*, digit grouping is checked...
6448 <p><b>Rationale:</b></p>
6449 <p>This would be a change: as it stands, the standard clearly
6450 specifies that grouping applies to void*. A survey of existing
6451 practice shows that most existing implementations do that, as they
6459 <h3><a name="366"></a>366. Excessive const-qualification</h3>
6460 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6461 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2010-10-29</p>
6462 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
6463 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6464 <p><b>Discussion:</b></p>
6466 The following member functions are declared const, yet return non-const
6467 pointers. We believe they are should be changed, because they allow code
6468 that may surprise the user. See document N1360 for details and
6472 <p><i>[Santa Cruz: the real issue is that we've got const member
6473 functions that return pointers to non-const, and N1360 proposes
6474 replacing them by overloaded pairs. There isn't a consensus about
6475 whether this is a real issue, since we've never said what our
6476 constness policy is for iostreams. N1360 relies on a distinction
6477 between physical constness and logical constness; that distinction, or
6478 those terms, does not appear in the standard.]</i></p>
6483 <p><b>Proposed resolution:</b></p>
6484 <p>In 27.4.4 and 27.4.4.2</p>
6486 <pre> basic_ostream<charT,traits>* tie() const;
6489 <pre> basic_ostream<charT,traits>* tie();
6490 const basic_ostream<charT,traits>* tie() const;
6494 <pre> basic_streambuf<charT,traits>* rdbuf() const;
6497 <pre> basic_streambuf<charT,traits>* rdbuf();
6498 const basic_streambuf<charT,traits>* rdbuf() const;
6501 <p>In 27.5.2 and 27.5.2.3.1</p>
6503 <pre> char_type* eback() const;
6506 <pre> char_type* eback();
6507 const char_type* eback() const;
6511 <pre> char_type gptr() const;
6514 <pre> char_type* gptr();
6515 const char_type* gptr() const;
6519 <pre> char_type* egptr() const;
6522 <pre> char_type* egptr();
6523 const char_type* egptr() const;
6526 <p>In 27.5.2 and 27.5.2.3.2</p>
6528 <pre> char_type* pbase() const;
6531 <pre> char_type* pbase();
6532 const char_type* pbase() const;
6536 <pre> char_type* pptr() const;
6539 <pre> char_type* pptr();
6540 const char_type* pptr() const;
6544 <pre> char_type* epptr() const;
6547 <pre> char_type* epptr();
6548 const char_type* epptr() const;
6551 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
6553 <pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
6556 <pre> basic_stringbuf<charT,traits,Allocator>* rdbuf();
6557 const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
6560 <p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
6562 <pre> basic_filebuf<charT,traits>* rdbuf() const;
6565 <pre> basic_filebuf<charT,traits>* rdbuf();
6566 const basic_filebuf<charT,traits>* rdbuf() const;
6570 <p><b>Rationale:</b></p>
6571 <p>The existing specification is a bit sloppy, but there's no
6572 particular reason to change this other than tidiness, and there are
6573 a number of ways in which streams might have been designed
6574 differently if we were starting today. There's no evidence that the
6575 existing constness policy is harming users. We might consider
6576 a different constness policy as part of a full stream redesign.</p>
6583 <h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
6584 <p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6585 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2002-05-13 <b>Last modified:</b> 2010-10-29</p>
6586 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
6587 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6588 <p><b>Discussion:</b></p>
6590 remove_copy and remove_copy_if (25.3.8 [alg.remove]) permit their
6591 input range to be marked with Input Iterators. However, since two
6592 operations are required against the elements to copy (comparison and
6593 assigment), when the input range uses Input Iterators, a temporary
6594 copy must be taken to avoid dereferencing the iterator twice. This
6595 therefore requires the value type of the InputIterator to be
6596 CopyConstructible. If the iterators are at least Forward Iterators,
6597 then the iterator can be dereferenced twice, or a reference to the
6598 result maintained, so the temporary is not required.
6602 <p><b>Proposed resolution:</b></p>
6604 Add "If InputIterator does not meet the requirements of forward
6605 iterator, then the value type of InputIterator must be copy
6606 constructible. Otherwise copy constructible is not required." to
6607 25.3.8 [alg.remove] paragraph 6.
6611 <p><b>Rationale:</b></p>
6612 <p>The assumption is that an input iterator can't be dereferenced
6613 twice. There's no basis for that assumption in the Standard.</p>
6620 <h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
6621 <p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
6622 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2002-06-03 <b>Last modified:</b> 2010-10-29</p>
6623 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::replace">issues</a> in [string::replace].</p>
6624 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
6625 <p><b>Discussion:</b></p>
6627 21.4.6.6 [string::replace] basic_string::replace, second
6628 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
6633 In addition, the second "Throws" paragraph (5) includes specification
6634 (beginning with "Otherwise, the function replaces ...") that should be
6635 part of the "Effects" paragraph.
6639 <p><b>Proposed resolution:</b></p>
6642 <p><b>Rationale:</b></p>
6643 <p>This is editorial. Both "throws" statements are true. The bug is
6644 just that the second one should be a sentence, part of the "Effects"
6645 clause, not a separate "Throws". The project editor has been
6653 <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
6654 <p><b>Section:</b> 17.6.4.12 [res.on.exception.handling], 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6655 <b>Submitter:</b> Randy Maddox <b>Opened:</b> 2002-07-22 <b>Last modified:</b> 2010-10-29</p>
6656 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
6657 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6658 <p><b>Discussion:</b></p>
6660 <p>Paragraph 3 under clause 17.6.4.12 [res.on.exception.handling], Restrictions on
6661 Exception Handling, states that "Any other functions defined in the
6662 C++ Standard Library that do not have an exception-specification may
6663 throw implementation-defined exceptions unless otherwise specified."
6664 This statement is followed by a reference to footnote 178 at the
6665 bottom of that page which states, apparently in reference to the C++
6666 Standard Library, that "Library implementations are encouraged (but
6667 not required) to report errors by throwing exceptions from (or derived
6668 from) the standard exceptions."</p>
6670 <p>These statements appear to be in direct contradiction to clause
6671 18.7.1 [type.info], which states "The class exception defines the
6672 base class for the types of objects thrown as exceptions by the C++
6673 Standard library components ...".</p>
6675 <p>Is this inconsistent?</p>
6679 <p><b>Proposed resolution:</b></p>
6682 <p><b>Rationale:</b></p>
6683 <p>Clause 17 is setting the overall library requirements, and it's
6684 clear and consistent. This sentence from Clause 18 is descriptive,
6685 not setting a requirement on any other class.
6693 <h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
6694 <p><b>Section:</b> 22.4.6.3.1 [locale.moneypunct.members], 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6695 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-08 <b>Last modified:</b> 2010-10-29</p>
6696 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6697 <p><b>Discussion:</b></p>
6699 In section 22.4.6.3.1 [locale.moneypunct.members], frac_digits() returns type
6700 "int". This implies that frac_digits() might return a negative value,
6701 but a negative value is nonsensical. It should return "unsigned".
6705 Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
6706 should return "unsigned".
6711 <p><b>Proposed resolution:</b></p>
6714 <p><b>Rationale:</b></p>
6715 <p>Regardless of whether the return value is int or unsigned, it's
6716 always conceivable that frac_digits might return a nonsensical
6717 value. (Is 4294967295 really any better than -1?) The clients of
6718 moneypunct, the get and put facets, can and do perform range
6726 <h3><a name="377"></a>377. basic_string::insert and length_error</h3>
6727 <p><b>Section:</b> 21.4.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6728 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-16 <b>Last modified:</b> 2010-10-29</p>
6729 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
6730 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6731 <p><b>Discussion:</b></p>
6733 Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
6734 "Then throws length_error if size() >= npos - rlen."
6738 Related to DR 83, this sentence should probably be removed.
6742 <p><b>Proposed resolution:</b></p>
6745 <p><b>Rationale:</b></p><p>This requirement is redundant but correct. No change is
6752 <h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
6753 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6754 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
6755 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
6756 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6757 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
6758 <p><b>Discussion:</b></p>
6760 I think there is a problem with 22.1.1, p6 which says that
6762 <pre> -6- An instance of locale is immutable; once a facet reference
6763 is obtained from it, that reference remains usable as long
6764 as the locale value itself exists.
6769 <pre> const locale& operator=(const locale& other) throw();
6771 -4- Effects: Creates a copy of other, replacing the current value.
6774 How can a reference to a facet obtained from a locale object remain
6775 valid after an assignment that clearly must replace all the facets
6776 in the locale object? Imagine a program such as this
6778 <pre> std::locale loc ("de_DE");
6779 const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
6780 loc = std::locale ("en_US");
6781 const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
6784 Is r0 really supposed to be preserved and destroyed only when loc goes
6789 <p><b>Proposed resolution:</b></p>
6790 <p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
6791 is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
6801 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
6802 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6803 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-08-30 <b>Last modified:</b> 2010-10-29</p>
6804 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
6805 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6806 <p><b>Discussion:</b></p>
6808 It seems that the descriptions of codecvt do_in() and do_out() leave
6809 sufficient room for interpretation so that two implementations of
6810 codecvt may not work correctly with the same filebuf. Specifically,
6811 the following seems less than adequately specified:
6816 the conditions under which the functions terminate
6819 precisely when the functions return ok
6822 precisely when the functions return partial
6825 the full set of conditions when the functions return error
6831 22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
6832 function: ...Stops if it encounters a character it cannot
6833 convert... This assumes that there *is* a character to
6834 convert. What happens when there is a sequence that doesn't form a
6835 valid source character, such as an unassigned or invalid UNICODE
6836 character, or a sequence that cannot possibly form a character
6837 (e.g., the sequence "\xc0\xff" in UTF-8)?
6840 Table 53 says that the function returns codecvt_base::ok
6841 to indicate that the function(s) "completed the conversion."
6842 Suppose that the source sequence is "\xc0\x80" in UTF-8,
6843 with from pointing to '\xc0' and (from_end==from + 1).
6844 It is not clear whether the return value should be ok
6845 or partial (see below).
6848 Table 53 says that the function returns codecvt_base::partial
6849 if "not all source characters converted." With the from pointers
6850 set up the same way as above, it is not clear whether the return
6851 value should be partial or ok (see above).
6854 Table 53, in the row describing the meaning of error mistakenly
6855 refers to a "from_type" character, without the symbol from_type
6856 having been defined. Most likely, the word "source" character
6857 is intended, although that is not sufficient. The functions
6858 may also fail when they encounter an invalid source sequence
6859 that cannot possibly form a valid source character (e.g., as
6860 explained in bullet 1 above).
6864 Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
6867 "A return value of partial, if (from_next == from_end),
6868 indicates that either the destination sequence has not
6869 absorbed all the available destination elements, or that
6870 additional source elements are needed before another
6871 destination element can be produced."
6874 If the value is partial, it's not clear to me that (from_next
6875 ==from_end) could ever hold if there isn't enough room
6876 in the destination buffer. In order for (from_next==from_end) to
6877 hold, all characters in that range must have been successfully
6878 converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
6879 further source characters to convert, no more room in the
6880 destination buffer can be needed.
6883 It's also not clear to me that (from_next==from_end) could ever
6884 hold if additional source elements are needed to produce another
6885 destination character (not element as incorrectly stated in the
6886 text). partial is returned if "not all source characters have
6887 been converted" according to Table 53, which also implies that
6888 (from_next==from) does NOT hold.
6891 Could it be that the intended qualifying condition was actually
6892 (from_next != from_end), i.e., that the sentence was supposed
6896 "A return value of partial, if (from_next != from_end),..."
6899 which would make perfect sense, since, as far as I understand it,
6900 partial can only occur if (from_next != from_end)?
6902 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
6903 fixed. Right now, the description of codecvt is too vague for it to
6904 be a useful contract between providers and clients of codecvt
6905 facets. (Note that both vendors and users can be both providers and
6906 clients of codecvt facets.) The major philosophical issue is whether
6907 the standard should only describe mappings that take a single wide
6908 character to multiple narrow characters (and vice versa), or whether
6909 it should describe fully general N-to-M conversions. When the
6910 original standard was written only the former was contemplated, but
6911 today, in light of the popularity of utf8 and utf16, that doesn't
6912 seem sufficient for C++0x. Bill supports general N-to-M conversions;
6913 we need to make sure Martin and Howard agree.]</i></p>
6923 codecvt is meant to be a 1-to-N to N-to-1 conversion. It does not work
6924 well for N-to-M conversions. wbuffer_convert now exists, and handles
6925 N-to-M cases. Also, there is a new specialization of codecvt that
6926 permits UTF-16 <-> UTF-8 conversions.
6929 NAD without prejudice. Will reopen if proposed resolution is supplied.
6935 <p><b>Proposed resolution:</b></p>
6941 <h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
6942 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6943 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2010-10-29</p>
6944 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
6945 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
6946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6947 <p><b>Discussion:</b></p>
6949 Many function templates have parameters that are passed by value;
6950 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
6951 25.2.5 [alg.find]. Are the corresponding template parameters
6952 (<tt>Predicate</tt> in this case) implicitly required to be
6953 CopyConstructible, or does that need to be spelled out explicitly?
6957 This isn't quite as silly a question as it might seem to be at first
6958 sight. If you call <tt>find_if</tt> in such a way that template
6959 argument deduction applies, then of course you'll get call by value
6960 and you need to provide a copy constructor. If you explicitly provide
6961 the template arguments, however, you can force call by reference by
6962 writing something like <tt>find_if<my_iterator,
6963 my_predicate&></tt>. The question is whether implementation
6964 are required to accept this, or whether this is ill-formed because
6965 my_predicate& is not CopyConstructible.
6969 The scope of this problem, if it is a problem, is unknown. Function
6970 object arguments to generic algorithms in clauses 25 [algorithms]
6971 and 26 [numerics] are obvious examples. A review of the whole
6972 library is necessary.
6975 This is really two issues. First, predicates are typically passed by
6976 value but we don't say they must be Copy Constructible. They should
6977 be. Second: is specialization allowed to transform value arguments
6978 into references? References aren't copy constructible, so this should
6983 2007-01-12, Howard: First, despite the note above, references <b>are</b>
6984 copy constructible. They just aren't assignable. Second, this is very
6985 closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
6986 That issue already says that implementations are allowed to copy
6987 function objects. If one passes in a reference, it is copyable, but
6988 susceptible to slicing if one passes in a reference to a base. Third,
6989 with rvalue reference in the language one only needs to satisfy
6990 MoveConstructible to pass an rvalue "by value". Though the function
6991 might still copy the function object internally (requiring
6992 CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
6993 code all of the std::algorithms such that they do not copy function
6994 objects internally. One merely passes them by reference internally if
6995 desired (this has been fully implemented and shipped for several years).
6996 If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
6997 function objects to reliably maintain state. E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
7002 <p><b>Proposed resolution:</b></p>
7008 <p><b>Rationale:</b></p>
7010 Generic algorithms will be marked with concepts and these will imply a requirement
7011 of MoveConstructible (not CopyConstructible). The signature of the function will
7012 then precisely describe and enforce the precise requirements.
7020 <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
7021 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7022 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2010-10-29</p>
7023 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
7024 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7025 <p><b>Discussion:</b></p>
7027 Practice with std::complex<> and the associative containers
7028 occasionally reveals artificial and distracting issues with constructs
7029 resembling: std::set<std::complex<double> > s;
7033 The main reason for the above to fail is the absence of an approriate
7034 definition for std::less<std::complex<T> >. That in turn comes from
7035 the definition of the primary template std::less<> in terms of
7040 The usual argument goes as follows: Since there is no ordering over
7041 the complex field compatible with field operations it makes little
7042 sense to define a function operator< operating on the datatype
7043 std::complex<T>. That is fine. However, that reasoning does not carry
7044 over to std::less<T> which is used, among other things, by associative
7045 containers as an ordering useful to meet complexity requirements.
7048 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
7051 Pre Bellevue: Reopened at the request of Alisdair.
7061 This is a request for a design change, and not a defect in the standard.
7062 It is in scope to consider, but the group feels that it is not a change
7063 that we need to do. Is there a total ordering for floating point values,
7064 including NaN? There is not a clear enough solution or big enough
7065 problem for us to solve. Solving this problem would require solving the
7066 problem for floating point, which is equally unclear. The LWG noted that
7067 users who want to put objects into an associative container for which
7068 operator< isn't defined can simply provide their own comparison function
7073 <p><b>Proposed resolution:</b></p>
7074 <p>Informally: Add a specialization of std::less for std::complex.</p>
7077 <p><b>Rationale:</b></p>
7078 <p>Discussed in Santa Cruz. An overwhelming majority of the LWG
7079 believes this should not be treated a DR: it's a request for a design
7080 change, not a defect in the existing standard. Most people (10-3)
7081 believed that we probably don't want this change, period: as with
7082 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
7083 The LWG noted that users who want to put objects into an associative
7084 container for which <tt>operator<</tt> isn't defined can simply
7085 provide their own comparison function object.</p>
7092 <h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
7093 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
7094 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2002-10-24 <b>Last modified:</b> 2010-10-29</p>
7095 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
7096 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
7097 <p><b>Discussion:</b></p>
7099 The CopyConstructible requirements in Table 30 state that for an
7100 object t of type T (where T is CopyConstructible), the expression &t
7101 returns the address of t (with type T*). This requirement is overly
7102 strict, in that it disallows types that overload operator& to not
7103 return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
7104 operator& is overloaded for a Boost.Lambda function object to return
7105 another function object.
7110 <pre> std::vector<int> u, v;
7113 std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
7117 _1 * x returns an unnamed function object with operator& overloaded to
7118 not return T* , therefore rendering the std::transform call ill-formed.
7119 However, most standard library implementations will compile this code
7120 properly, and the viability of such binder libraries is severely hindered
7121 by the unnecessary restriction in the CopyConstructible requirements.
7125 For reference, the address of an object can be retrieved without using
7126 the address-of operator with the following function template:
7129 <pre> template <typename T> T* addressof(T& v)
7131 return reinterpret_cast<T*>(
7132 &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
7137 Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
7138 will need to be reexamined if the CopyConstructible requirements
7143 <p><b>Proposed resolution:</b></p>
7145 Remove the last two rows of Table 30, eliminating the requirements
7146 that &t and &u return the address of t and u, respectively.
7150 <p><b>Rationale:</b></p>
7151 <p>This was a deliberate design decision. Perhaps it should be
7152 reconsidered for C++0x. </p>
7159 <h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
7160 <p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7161 <b>Submitter:</b> Corwin Joy <b>Opened:</b> 2002-12-11 <b>Last modified:</b> 2010-10-29</p>
7162 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
7163 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7164 <p><b>Discussion:</b></p>
7167 In section 24.2.3 [input.iterators] table 72 -
7168 'Input Iterator Requirements' we have as a postcondition of *a:
7169 "If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
7173 In section 24.6.3.5 [istreambuf.iterator::equal] it states that
7174 "istreambuf_iterator::equal returns true if and only if both iterators
7175 are at end-of-stream, or neither is at end-of-stream, <i>regardless of
7176 what streambuf object they use</i>." (My emphasis).
7180 The defect is that either 'equivalent' needs to be more precisely
7181 defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal]
7182 are incorrect. (Or both).
7185 <p>Consider the following example:</p>
7186 <pre> #include <iostream>
7187 #include <fstream>
7188 #include <iterator>
7189 using namespace std;
7192 ifstream file1("file1.txt"), file2("file2.txt");
7193 istreambuf_iterator<char> f1(file1), f2(file2);
7194 cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl;
7195 cout << "f1 = " << *f1 << endl;
7196 cout << "f2 = " << *f2 << endl;
7201 <p>Now assuming that neither f1 or f2 are at the end-of-stream then
7202 f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].</p>
7204 <p>However, it is unlikely that *f1 will give the same value as *f2 except
7207 <p>So what does *f1 'equivalent' to *f2 mean? I think the standard should
7208 be clearer on this point, or at least be explicit that this does not
7209 mean that *f1 and *f2 are required to have the same value in the case
7210 of input iterators.</p>
7213 <p><b>Proposed resolution:</b></p>
7216 <p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
7224 <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
7225 <p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
7226 <b>Submitter:</b> Alberto Barbati <b>Opened:</b> 2002-12-24 <b>Last modified:</b> 2010-10-29</p>
7227 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
7228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
7229 <p><b>Discussion:</b></p>
7231 this DR follows the discussion on the previous thread "codecvt::do_in
7232 not consuming external characters". It's just a clarification issue
7233 and not a request for a change.
7236 Can do_in()/do_out() produce output characters without consuming input
7237 characters as a result of operation on state?
7241 <p><b>Proposed resolution:</b></p>
7243 Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals],
7248 [Note: As a result of operations on state, it can return ok or partial
7249 and set from_next == from and to_next != to. --end note]
7253 <p><b>Rationale:</b></p>
7255 The submitter believes that standard already provides an affirmative
7256 answer to the question. However, the current wording has induced a few
7257 library implementors to make the incorrect assumption that
7258 do_in()/do_out() always consume at least one internal character when
7263 The submitter also believes that the proposed resolution is not in
7264 conflict with the related issue 76. Moreover, by explicitly allowing
7265 operations on state to produce characters, a codecvt implementation
7266 may effectively implement N-to-M translations without violating the
7267 "one character at a time" principle described in such issue. On a side
7268 note, the footnote in the proposed resolution of issue 76 that
7269 informally rules out N-to-M translations for basic_filebuf should be
7270 removed if this issue is accepted as valid.
7275 Kona (2007): The proposed resolution is to add a note. Since this is
7276 non-normative, the issue is editorial, but we believe that the note is
7277 correct. Proposed Disposition: NAD, Editorial
7286 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
7287 <p><b>Section:</b> 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7288 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-12-27 <b>Last modified:</b> 2010-10-29</p>
7289 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7290 <p><b>Discussion:</b></p>
7292 There is a contradiction in Formatted output about what bit is
7293 supposed to be set if the formatting fails. On sentence says it's
7294 badbit and another that it's failbit.
7297 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
7300 <pre> ... If the generation fails, then the formatted output function
7301 does setstate(ios::failbit), which might throw an exception.
7304 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
7307 ... The formatting conversion occurs as if it performed the
7308 following code fragment:
7311 use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
7313 (getloc()).put(*this, *this, fill(), val). failed();
7315 ... If failed is true then does setstate(badbit) ...
7318 The original intent of the text, according to Jerry Schwarz (see
7319 c++std-lib-10500), is captured in the following paragraph:
7322 In general "badbit" should mean that the stream is unusable because
7323 of some underlying failure, such as disk full or socket closure;
7324 "failbit" should mean that the requested formatting wasn't possible
7325 because of some inconsistency such as negative widths. So typically
7326 if you clear badbit and try to output something else you'll fail
7327 again, but if you clear failbit and try to output something else
7331 In the case of the arithmetic inserters, since num_put cannot
7332 report failure by any means other than exceptions (in response
7333 to which the stream must set badbit, which prevents the kind of
7334 recoverable error reporting mentioned above), the only other
7335 detectable failure is if the iterator returned from num_put
7336 returns true from failed().
7339 Since that can only happen (at least with the required iostream
7340 specializations) under such conditions as the underlying failure
7341 referred to above (e.g., disk full), setting badbit would seem
7342 to be the appropriate response (indeed, it is required in
7343 27.6.2.5.2, p1). It follows that failbit can never be directly
7344 set by the arithmetic (it can only be set by the sentry object
7345 under some unspecified conditions).
7348 The situation is different for other formatted output functions
7349 which can fail as a result of the streambuf functions failing
7350 (they may do so by means other than exceptions), and which are
7351 then required to set failbit.
7354 The contradiction, then, is that ostream::operator<<(int) will
7355 set badbit if the disk is full, while operator<<(ostream&,
7356 char) will set failbit under the same conditions. To make the behavior
7357 consistent, the Common requirements sections for the Formatted output
7358 functions should be changed as proposed below.
7360 <p><i>[Kona: There's agreement that this is a real issue. What we
7361 decided at Kona: 1. An error from the buffer (which can be detected
7362 either directly from streambuf's member functions or by examining a
7363 streambuf_iterator) should always result in badbit getting set.
7364 2. There should never be a circumstance where failbit gets set.
7365 That represents a formatting error, and there are no circumstances
7366 under which the output facets are specified as signaling a
7367 formatting error. (Even more so for string output that for numeric
7368 because there's nothing to format.) If we ever decide to make it
7369 possible for formatting errors to exist then the facets can signal
7370 the error directly, and that should go in clause 22, not clause 27.
7371 3. The phrase "if generation fails" is unclear and should be
7372 eliminated. It's not clear whether it's intended to mean a buffer
7373 error (e.g. a full disk), a formatting error, or something else.
7374 Most people thought it was supposed to refer to buffer errors; if
7375 so, we should say so. Martin will provide wording.]</i></p>
7384 NAD. This issue is already fixed.
7389 <p><b>Proposed resolution:</b></p>
7392 <p><b>Rationale:</b></p>
7400 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
7401 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
7402 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2010-10-29</p>
7403 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
7404 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
7405 <p><b>Discussion:</b></p>
7407 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
7410 27.6.2.3, p4 says this about the ostream::sentry dtor:
7412 <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
7413 is true, calls os.flush().
7416 27.6.2.6, p7 that describes ostream::flush() says:
7418 <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
7419 If that function returns ?-1 calls setstate(badbit) (which
7420 may throw ios_base::failure (27.4.4.3)).
7423 That seems like a defect, since both pubsync() and setstate() can
7427 The contradiction is real. Clause 17 says destructors may never
7428 throw exceptions, and clause 27 specifies a destructor that does
7429 throw. In principle we might change either one. We're leaning
7430 toward changing clause 17: putting in an "unless otherwise specified"
7431 clause, and then putting in a footnote saying the sentry destructor
7432 is the only one that can throw. PJP suggests specifying that
7433 sentry::~sentry() should internally catch any exceptions it might cause.
7438 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
7449 Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~sentry().
7454 2009-10-13 Daniel adds:
7459 The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a> is written to match the outcome
7469 Move to Open. Our intent is to solve this issue with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>.
7473 2010-03-06 Martin updates wording.
7483 Moved to NAD Editorial.
7488 <p><b>Rationale:</b></p>
7490 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>.
7494 <p><b>Proposed resolution:</b></p>
7496 Add after 27.7.2.4 [ostream::sentry] p17:
7504 -17- If <tt>(os.flags() & ios_base::unitbuf)</tt>
7505 is <tt>true</tt>, calls <tt>os.flush()</tt>.
7509 <i>Throws:</i> Nothing.
7519 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
7520 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7521 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2010-10-29</p>
7522 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
7523 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7524 <p><b>Discussion:</b></p>
7526 While reviewing unformatted input member functions of istream
7527 for their behavior when they encounter end-of-file during input
7528 I found that the requirements vary, sometimes unexpectedly, and
7529 in more than one case even contradict established practice (GNU
7530 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
7531 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
7534 The following unformatted input member functions set eofbit if they
7535 encounter an end-of-file (this is the expected behavior, and also
7536 the behavior of all major implementations):
7538 <pre> basic_istream<charT, traits>&
7539 get (char_type*, streamsize, char_type);
7542 Also sets failbit if it fails to extract any characters.
7544 <pre> basic_istream<charT, traits>&
7545 get (char_type*, streamsize);
7548 Also sets failbit if it fails to extract any characters.
7550 <pre> basic_istream<charT, traits>&
7551 getline (char_type*, streamsize, char_type);
7554 Also sets failbit if it fails to extract any characters.
7556 <pre> basic_istream<charT, traits>&
7557 getline (char_type*, streamsize);
7560 Also sets failbit if it fails to extract any characters.
7562 <pre> basic_istream<charT, traits>&
7563 ignore (int, int_type);
7565 <pre> basic_istream<charT, traits>&
7566 read (char_type*, streamsize);
7569 Also sets failbit if it encounters end-of-file.
7571 <pre> streamsize readsome (char_type*, streamsize);
7575 The following unformated input member functions set failbit but
7576 not eofbit if they encounter an end-of-file (I find this odd
7577 since the functions make it impossible to distinguish a general
7578 failure from a failure due to end-of-file; the requirement is
7579 also in conflict with all major implementation which set both
7580 eofbit and failbit):
7582 <pre> int_type get();
7584 <pre> basic_istream<charT, traits>&
7585 get (char_type&);
7588 These functions only set failbit of they extract no characters,
7589 otherwise they don't set any bits, even on failure (I find this
7590 inconsistency quite unexpected; the requirement is also in
7591 conflict with all major implementations which set eofbit
7592 whenever they encounter end-of-file):
7594 <pre> basic_istream<charT, traits>&
7595 get (basic_streambuf<charT, traits>&, char_type);
7597 <pre> basic_istream<charT, traits>&
7598 get (basic_streambuf<charT, traits>&);
7601 This function sets no bits (all implementations except for
7602 STLport and Classic Iostreams set eofbit when they encounter
7605 <pre> int_type peek ();
7607 <p>Informally, what we want is a global statement of intent saying
7608 that eofbit gets set if we trip across EOF, and then we can take
7609 away the specific wording for individual functions. A full review
7610 is necessary. The wording currently in the standard is a mishmash,
7611 and changing it on an individual basis wouldn't make things better.
7612 Dietmar will do this work.</p>
7620 Moved to NAD. See 27.7.1.1 [istream] p3.
7625 <p><b>Proposed resolution:</b></p>
7631 <h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
7632 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7633 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2010-10-29</p>
7634 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
7635 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7636 <p><b>Discussion:</b></p>
7638 The Effects clauses for the two functions below violate the
7639 general requirements on unformatted input functions outlined
7640 in 27.6.1.3: they do not begin by constructing a sentry object.
7641 Instead, they begin by calling widen ('\n'), which may throw
7642 an exception. The exception is then allowed to propagate from
7643 the unformatted input function irrespective of the setting of
7647 Note that in light of 27.6.1.1, p3 and p4, the fact that the
7648 functions allow exceptions thrown from widen() to propagate
7649 may not strictly speaking be a defect (but the fact that the
7650 functions do not start by constructing a sentry object still
7651 is). However, since an exception thrown from ctype<charT>
7652 ::widen() during any other input operation (say, from within
7653 a call to num_get<charT>::get()) will be caught and cause
7654 badbit to be set, these two functions should not be treated
7655 differently for the sake of consistency.
7659 <p><b>Proposed resolution:</b></p>
7662 <p><b>Rationale:</b></p>
7664 Not a defect. The standard is consistent, and the behavior required
7665 by the standard is unambiguous. Yes, it's theoretically possible for
7666 widen to throw. (Not that this will happen for the default ctype
7667 facet or for most real-world replacement ctype facets.) Users who
7668 define ctype facets that can throw, and who care about this behavior,
7669 can use alternative signatures that don't call widen.
7678 <h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</h3>
7679 <p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
7680 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2010-10-29</p>
7681 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
7682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
7683 <p><b>Discussion:</b></p>
7685 I've been discussing iterator semantics with Dave Abrahams, and a
7686 surprise has popped up. I don't think this has been discussed before.
7690 X [iterator.concepts] says that the only operation that can be performed on "singular"
7691 iterator values is to assign a non-singular value to them. (It
7692 doesn't say they can be destroyed, and that's probably a defect.)
7693 Some implementations have taken this to imply that there is no need
7694 to initialize the data member of a reverse_iterator<> in the default
7695 constructor. As a result, code like
7697 <blockquote><pre> std::vector<std::reverse_iterator<char*> > v(7);
7701 invokes undefined behavior, because it must default-initialize the
7702 vector elements, and then copy them to other storage. Of course many
7703 other vector operations on these adapters are also left undefined,
7704 and which those are is not reliably deducible from the standard.
7708 I don't think that 24.1 was meant to make standard-library iterator
7709 types unsafe. Rather, it was meant to restrict what operations may
7710 be performed by functions which take general user- and standard
7711 iterators as arguments, so that raw pointers would qualify as
7712 iterators. However, this is not clear in the text, others have come
7713 to the opposite conclusion.
7717 One question is whether the standard iterator adaptors have defined
7718 copy semantics. Another is whether they have defined destructor
7721 <blockquote><pre> { std::vector<std::reverse_iterator<char*> > v(7); }
7728 Note this is not a question of whether algorithms are allowed to
7729 rely on copy semantics for arbitrary iterators, just whether the
7730 types we actually supply support those operations. I believe the
7731 resolution must be expressed in terms of the semantics of the
7732 adapter's argument type. It should make clear that, e.g., the
7733 reverse_iterator<T> constructor is actually required to execute
7734 T(), and so copying is defined if the result of T() is copyable.
7738 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
7739 constructor more precisely, has some relevance to this issue.
7740 However, it is not the whole story.
7744 The issue was whether
7746 <blockquote><pre> reverse_iterator() { }
7751 <blockquote><pre> reverse_iterator() : current() { }
7755 The difference is when T is char*, where the first leaves the member
7756 uninitialized, and possibly equal to an existing pointer value, or
7757 (on some targets) may result in a hardware trap when copied.
7761 8.5 paragraph 5 seems to make clear that the second is required to
7762 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
7767 But that only takes care of reverse_iterator, and doesn't establish
7768 a policy for all iterators. (The reverse iterator adapter was just
7769 an example.) In particular, does my function
7771 <blockquote><pre> template <typename Iterator>
7772 void f() { std::vector<Iterator> v(7); }
7775 evoke undefined behavior for some conforming iterator definitions?
7776 I think it does, now, because vector<> will destroy those singular
7777 iterator values, and that's explicitly disallowed.
7781 24.1 shouldn't give blanket permission to copy all singular iterators,
7782 because then pointers wouldn't qualify as iterators. However, it
7783 should allow copying of that subset of singular iterator values that
7784 are default-initialized, and it should explicitly allow destroying any
7785 iterator value, singular or not, default-initialized or not.
7788 <p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a></p>
7790 We don't want to require all singular iterators to be copyable,
7791 because that is not the case for pointers. However, default
7792 construction may be a special case. Issue: is it really default
7793 construction we want to talk about, or is it something like value
7794 initialization? We need to check with core to see whether default
7795 constructed pointers are required to be copyable; if not, it would be
7796 wrong to impose so strict a requirement for iterators.
7801 2009-05-10 Alisdair provided wording.
7806 The comments regarding destroying singular iterators have already been
7807 resolved. That just leaves copying (with moving implied).
7817 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>.
7820 Note that there is a bug in the proposed resolution to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>. The
7821 change to [reverse.iter.con] should be modified so that the word
7822 "default" in the second sentence of the Effects clause is replaced by
7826 We believe that the proposed fix to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a> (now corrected) is
7827 sufficient to solve the problem for reverse_iterator. However, Alisdair
7828 pointed out that LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a> does not solve the general problem for authors
7829 of iterator adaptors.
7832 There are some problems with the proposed resolution. The phrase "safely
7833 copyable" is not a term of art. Also, it mentions a
7834 DefaultConstructible? concept.
7837 Move to Review after Alisdair updates the wording.
7842 2009-07-31 Alisdair revised wording:
7847 2009-08-17 Alisdair and Daniel collaborate on slightly revised wording.
7848 This issue depends upon <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>
7853 2009-10-14 Daniel adds:
7858 There is a clear dependency on <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, because the term "singular",
7859 which is used as part of the resolution, is not properly defined yet.
7868 Moved to Open. Alisdair will provide improved wording to make
7869 this have "value semantics" and otherwise behave like a valid iterator.
7873 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
7879 <p><b>Rationale:</b></p>
7882 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
7886 <p><b>Proposed resolution:</b></p>
7888 Add a new paragrpah to Iterator concepts 24.2 [iterator.requirements] after para 5 (the one describing
7893 Just as a regular pointer to an array guarantees that there is a pointer
7894 value pointing past the last element of the array, so for any iterator
7895 type there is an iterator value that points past the last element of a
7896 corresponding container. These values are called <i>past-the-end</i> values.
7897 Values of an iterator <tt>i</tt> for which the expression <tt>*i</tt> is defined are called
7898 <i>dereferenceable</i>. The library never assumes that past-the-end values are
7899 dereferenceable. Iterators can also have singular values that are not
7900 associated with any container. [<i>Example:</i> After the declaration of an
7901 uninitialized pointer <tt>x</tt> (as with <tt>int* x;</tt>), <tt>x</tt> must always be assumed to
7902 have a singular value of a pointer.
\97 <i>end example</i>] Results of most
7903 expressions are undefined for singular values; the only exceptions are
7904 destroying an iterator that holds a singular value and the assignment of
7905 a non-singular value to an iterator that holds a singular value. In this
7906 case the singular value is overwritten the same way as any other value.
7907 Dereferenceable values are always non-singular.
7910 After value-initialization, any iterator that satisfies the
7911 <tt>DefaultConstructible</tt> requirements ([defaultconstructible]) shall not introduce undefined behaviour
7912 when used <ins>as</ins> the
7913 source of a copy or move operation, even if it would
7914 otherwise be singular. [<i>Note:</i> This guarantee is not offered for
7915 default-initialization (8.5 [dcl.init]), although the distinction only
7916 matters for types with trivial default constructors such as pointers.
\97
7929 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
7930 <p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7931 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
7932 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
7933 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7934 <p><b>Discussion:</b></p>
7936 The Effects and Returns clauses of the do_widen() member function of
7937 the ctype facet fail to specify the behavior of the function on failure.
7938 That the function may not be able to simply cast the narrow character
7939 argument to the type of the result since doing so may yield the wrong value
7940 for some wchar_t encodings. Popular implementations of ctype<wchar_t> that
7941 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
7942 when the argument's MSB is set. There is no way for the the rest of locale
7943 and iostream to reliably detect this failure.
7945 <p><i>[Kona: This is a real problem. Widening can fail. It's unclear
7946 what the solution should be. Returning WEOF works for the wchar_t
7947 specialization, but not in general. One option might be to add a
7948 default, like <i>narrow</i>. But that's an incompatible change.
7949 Using <i>traits::eof</i> might seem like a good idea, but facets
7950 don't have access to traits (a recurring problem). We could
7951 have <i>widen</i> throw an exception, but that's a scary option;
7952 existing library components aren't written with the assumption
7953 that <i>widen</i> can throw.]</i></p>
7962 NAD. The behavior is specified for all of the facets that an
7963 implementation is required to provide, for the basic character set.
7968 <p><b>Proposed resolution:</b></p>
7974 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
7975 <p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7976 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
7977 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
7978 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7979 <p><b>Discussion:</b></p>
7981 The dtor of the ios_base::Init object is supposed to call flush() on the
7982 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
7983 This call may cause an exception to be thrown.
7987 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
7991 The question is: What should this dtor do if one or more of these calls
7992 to flush() ends up throwing an exception? This can happen quite easily
7993 if one of the facets installed in the locale imbued in the iostream
7996 <p><i>[Kona: We probably can't do much better than what we've got, so
7997 the LWG is leaning toward NAD. At the point where the standard
7998 stream objects are being cleaned up, the usual error reporting
7999 mechanism are all unavailable. And exception from flush at this
8000 point will definitely cause problems. A quality implementation
8001 might reasonably swallow the exception, or call abort, or do
8002 something even more drastic.]</i></p>
8006 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
8016 Moved to NAD, no consensus for change.
8021 <p><b>Proposed resolution:</b></p>
8027 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
8028 <p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8029 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
8030 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
8031 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8032 <p><b>Discussion:</b></p>
8034 The reflector thread starting with c++std-lib-11346 notes that the class
8035 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
8036 is copy-constructible but that the semantics of the copy constructors
8037 are not defined anywhere. Further, different implementations behave
8038 differently in this respect: some prevent copy construction of objects
8039 of these types by declaring their copy ctors and assignment operators
8040 private, others exhibit undefined behavior, while others still give
8041 these operations well-defined semantics.
8045 Note that this problem doesn't seem to be isolated to just the three
8046 types mentioned above. A number of other types in the library section
8047 of the standard provide a compiler-generated copy ctor and assignment
8048 operator yet fail to specify their semantics. It's believed that the
8049 only types for which this is actually a problem (i.e. types where the
8050 compiler-generated default may be inappropriate and may not have been
8051 intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
8060 NAD. Option B is already in the Working Draft.
8065 <p><b>Proposed resolution:</b></p>
8067 27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
8071 <pre>basic_streambuf(const basic_streambuf& sb);
8072 basic_streambuf& operator=(const basic_streambuf& sb);
8076 <p>Insert after 27.5.2.1, paragraph 2:</p>
8078 <pre>basic_streambuf(const basic_streambuf& sb);
8081 <p>Constructs a copy of sb.</p>
8082 <p>Postcondtions:</p>
8083 <pre> eback() == sb.eback()
8085 egptr() == sb.egptr()
8086 pbase() == sb.pbase()
8088 epptr() == sb.epptr()
8089 getloc() == sb.getloc()
8092 <pre>basic_streambuf& operator=(const basic_streambuf& sb);
8095 <p>Assigns the data members of sb to this.</p>
8097 <p>Postcondtions:</p>
8098 <pre> eback() == sb.eback()
8100 egptr() == sb.egptr()
8101 pbase() == sb.pbase()
8103 epptr() == sb.epptr()
8104 getloc() == sb.getloc()
8107 <p>Returns: *this.</p>
8110 <p>27.7.1 [lib.stringbuf]:</p>
8112 <p><b>Option A:</b></p>
8115 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
8117 <pre>basic_stringbuf(const basic_stringbuf&); // not defined
8118 basic_stringbuf& operator=(const basic_stringbuf&); // not defined
8122 <p><b>Option B:</b></p>
8125 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
8127 <pre>basic_stringbuf(const basic_stringbuf& sb);
8128 basic_stringbuf& operator=(const basic_stringbuf& sb);
8131 <p>27.7.1.1, insert after paragraph 4:</p>
8133 <pre>basic_stringbuf(const basic_stringbuf& sb);</pre>
8136 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
8139 <p>Postcondtions: </p>
8140 <pre> str() == sb.str()
8141 gptr() - eback() == sb.gptr() - sb.eback()
8142 egptr() - eback() == sb.egptr() - sb.eback()
8143 pptr() - pbase() == sb.pptr() - sb.pbase()
8144 getloc() == sb.getloc()
8148 Note: The only requirement on epptr() is that it point beyond the initialized range if an output sequence exists. There is no requirement that epptr() - pbase() == sb.epptr() - sb.pbase().
8151 <pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre>
8153 After assignment the basic_stringbuf has the same state as if it were initially copy constructed from sb, except that the basic_stringbuf is allowed to retain any excess capacity it might have, which may in turn effect the value of epptr().
8157 <p>27.8.1.1 [lib.filebuf]</p>
8159 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
8163 basic_filebuf(const basic_filebuf&); // not defined
8164 basic_filebuf& operator=(const basic_filebuf&); // not defined
8167 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
8168 derived classes. We are leaning toward allowing basic_streambuf to
8169 be copyable, and specifying its precise semantics. (Probably the
8170 obvious: copying the buffer pointers.) We are less sure whether
8171 the streambuf derived classes should be copyable. Howard will
8172 write up a proposal.]</i></p>
8175 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
8176 being copyable: it can lead to an encapsulation violation. Filebuf
8177 inherits from streambuf. Now suppose you inhert a my_hijacking_buf
8178 from streambuf. You can copy the streambuf portion of a filebuf to a
8179 my_hijacking_buf, giving you access to the pointers into the
8180 filebuf's internal buffer. Perhaps not a very strong argument, but
8181 it was strong enough to make people nervous. There was weak
8182 preference for having streambuf not be copyable. There was weak
8183 preference for having stringbuf not be copyable even if streambuf
8184 is. Move this issue to open for now.
8190 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
8191 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
8192 as would be generated by the compiler. These members aid in derived classes implementing move semantics.
8193 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
8194 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
8195 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather
8196 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
8197 move semantics less tedious and error prone.
8203 <p><b>Rationale:</b></p>
8205 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
8206 and assignment operator are the same as currently implied by the lack
8207 of declarations: public and simply copies the data members. This
8208 resolution is not a change but a clarification of the current
8213 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
8214 basic_stringbuf not copyable. This is likely the status-quo of
8215 current implementations. B) Reasonable copy semantics of
8216 basic_stringbuf can be defined and implemented. A copyable
8217 basic_streambuf is arguably more useful than a non-copyable one. This
8218 should be considered as new functionality and not the fixing of a
8219 defect. If option B is chosen, ramifications from issue 432 are taken
8224 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
8234 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
8235 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
8236 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
8237 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
8238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
8239 <p><b>Discussion:</b></p>
8242 A third party test suite tries to exercise istream::ignore(N) with
8243 a negative value of N and expects that the implementation will treat
8244 N as if it were 0. Our implementation asserts that (N >= 0) holds and
8249 I can't find anything in section 27 that prohibits such values but I don't
8250 see what the effects of such calls should be, either (this applies to
8251 a number of unformatted input functions as well as some member functions
8252 of the basic_streambuf template).
8262 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.
8271 <p><b>Proposed resolution:</b></p>
8273 I propose that we add to each function in clause 27 that takes an argument,
8274 say N, of type streamsize a Requires clause saying that "N >= 0." The intent
8275 is to allow negative streamsize values in calls to precision() and width()
8276 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
8280 <p><i>[Kona: The LWG agreed that this is probably what we want. However, we
8281 need a review to find all places where functions in clause 27 take
8282 arguments of type streamsize that shouldn't be allowed to go
8283 negative. Martin will do that review.]</i></p>
8291 <h3><a name="424"></a>424. normative notes</h3>
8292 <p><b>Section:</b> 17.5.1.2 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
8293 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
8294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
8295 <p><b>Discussion:</b></p>
8298 The text in 17.3.1.1, p1 says:
8301 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
8302 paragraphs are normative."
8305 The library section makes heavy use of paragraphs labeled "Notes(s),"
8306 some of which are clearly intended to be normative (see list 1), while
8307 some others are not (see list 2). There are also those where the intent
8308 is not so clear (see list 3).
8311 List 1 -- Examples of (presumably) normative Notes:
8314 20.9.5.1 [allocator.members], p3,<br>
8315 20.9.5.1 [allocator.members], p10,<br>
8316 21.4.2 [string.cons], p11,<br>
8317 22.3.1.2 [locale.cons], p11,<br>
8318 23.3.2.3 [deque.modifiers], p2,<br>
8319 25.4.7 [alg.min.max], p3,<br>
8320 26.4.6 [complex.ops], p15,<br>
8321 27.6.2.4.3 [streambuf.virt.get], p7.<br>
8324 List 2 -- Examples of (presumably) informative Notes:
8327 18.6.1.3 [new.delete.placement], p3,<br>
8328 21.4.6.6 [string::replace], p14,<br>
8329 22.4.1.4.2 [locale.codecvt.virtuals], p3,<br>
8330 25.2.4 [alg.foreach], p4,<br>
8331 26.4.5 [complex.member.ops], p1,<br>
8332 27.5.2.5 [ios.base.storage], p6.<br>
8335 List 3 -- Examples of Notes that are not clearly either normative
8339 22.3.1.2 [locale.cons], p8,<br>
8340 22.3.1.5 [locale.statics], p6,<br>
8341 27.6.2.4.5 [streambuf.virt.put], p4.<br>
8344 None of these lists is meant to be exhaustive.
8347 <p><i>[Definitely a real problem. The big problem is there's material
8348 that doesn't quite fit any of the named paragraph categories
8349 (e.g. <b>Effects</b>). Either we need a new kind of named
8350 paragraph, or we need to put more material in unnamed paragraphs
8351 jsut after the signature. We need to talk to the Project Editor
8352 about how to do this.
8357 Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
8358 22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
8359 will handle editorially.
8364 post San Francisco: Howard: reopened, needs attention.
8368 <p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
8369 Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004.
8370 Recommend NAD.]</i></p>
8374 Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i>
8375 to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for
8376 the same change. Alan and Pete to review.
8386 A spot-check of List 2 suggests the issue is still relevant,
8387 and a review of List 3 still seems called-for.
8390 Move to NAD Editorial.
8396 <p><b>Proposed resolution:</b></p>
8402 <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
8403 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8404 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
8405 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
8406 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8407 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
8408 <p><b>Discussion:</b></p>
8411 The Effects clause in 27.4.4.3, p5 describing the effects of a call to
8412 the ios_base member function clear(iostate state) says that the function
8413 only throws if the respective bits are already set prior to the function
8414 call. That's obviously not the intent. If it was, a call to clear(badbit)
8415 on an object for which (rdstate() == goodbit && exceptions() == badbit)
8416 holds would not result in an exception being thrown.
8420 <p><b>Proposed resolution:</b></p>
8423 The text ought to be changed from
8426 "If (rdstate() & exceptions()) == 0, returns. ..."
8432 "If (state & exceptions()) == 0, returns. ..."
8436 <p><b>Rationale:</b></p>
8444 <h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
8445 <p><b>Section:</b> D.13.3 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8446 <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Opened:</b> 2003-09-29 <b>Last modified:</b> 2010-10-29</p>
8447 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8448 <p><b>Discussion:</b></p>
8450 Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
8451 is called (18.7.2) immediately after completing the stack unwinding
8452 for the former function", but 18.7.2.4 (Effects) says that "void
8453 unexpected(); . . . Calls the unexpected_handler function in effect
8454 immediately after evaluating the throwexpression (18.7.2.2),". Isn't
8455 here a contradiction: 15.5.2 requires stack have been unwound when in
8456 void unexpected() and therefore in unexpected_handler but 18.7.2.4
8457 claims that unexpected_handler is called "in effect immediately" after
8458 evaluation of throw expression is finished, so there is no space left
8459 for stack to be unwound therefore? I think the phrase "in effect
8460 immediately" should be removed from the standard because it brings
8461 ambiguity in understanding.
8465 <p><b>Proposed resolution:</b></p>
8468 <p><b>Rationale:</b></p>
8469 <p>There is no contradiction. The phrase "in effect immediately" is
8470 just to clarify which handler is to be called.</p>
8477 <h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
8478 <p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8479 <b>Submitter:</b> Ivan Godard <b>Opened:</b> 2003-10-24 <b>Last modified:</b> 2010-10-29</p>
8480 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
8481 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8482 <p><b>Discussion:</b></p>
8492 (with the expected #include and usings), the value printed is a rather
8493 surprising "true". Rather useless too.
8496 <p>The standard defines:</p>
8498 <pre>ostream& operator<<(ostream&, void*);</pre>
8500 <p>which picks up all data pointers and prints their hex value, but does
8501 not pick up function pointers because there is no default conversion
8502 from function pointer to void*. Absent that, we fall back to legacy
8503 conversions from C and the function pointer is converted to bool.
8506 <p>There should be an analogous inserter that prints the address of a
8507 function pointer.</p>
8510 <p><b>Proposed resolution:</b></p>
8513 <p><b>Rationale:</b></p>
8514 <p>This is indeed a wart, but there is no good way to solve it. C
8515 doesn't provide a portable way of outputting the address of a
8516 function point either.</p>
8523 <h3><a name="439"></a>439. Should facets be copyable?</h3>
8524 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8525 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-02 <b>Last modified:</b> 2010-10-29</p>
8526 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
8527 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8528 <p><b>Discussion:</b></p>
8529 <p>The following facets classes have no copy constructors described in
8530 the standard, which, according to the standard, means that they are
8531 supposed to use the compiler-generated defaults. Default copy
8532 behavior is probably inappropriate. We should either make these
8533 classes uncopyable or else specify exactly what their constructors do.</p>
8535 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>.</p>
8541 ctype_byname<char>
8568 <p><b>Proposed resolution:</b></p>
8571 <p><b>Rationale:</b></p>
8572 <p>The copy constructor in the base class is private.</p>
8579 <h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
8580 <p><b>Section:</b> 26.4.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8581 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-05 <b>Last modified:</b> 2010-10-29</p>
8582 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8583 <p><b>Discussion:</b></p>
8585 Operations like <tt>pow</tt> and <tt>exp</tt> on
8586 <tt>complex<T></tt> are typically implemented in terms of
8587 operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
8588 Should implementations write this as <tt>std::sin</tt>, or as plain
8589 unqualified <tt>sin</tt>?
8592 <p>The issue, of course, is whether we want to use
8593 argument-dependent lookup in the case where <tt>T</tt> is a
8594 user-defined type. This is similar to the issue of valarray
8595 transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
8597 <p>This issue differs from valarray transcendentals in two important
8598 ways. First, "the effect of instantiating the template
8599 <tt>complex</tt> for types other than float, double or long double is
8600 unspecified." (26.4.1 [complex.syn]) Second, the standard does not
8601 dictate implementation, so there is no guarantee that a particular
8602 real math function is used in the implementation of a particular
8603 complex function.</p>
8607 <p><b>Proposed resolution:</b></p>
8610 <p><b>Rationale:</b></p>
8611 <p>If you instantiate std::complex for user-defined types, all bets
8619 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
8620 <p><b>Section:</b> 24.2 [iterator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
8621 <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16 <b>Last modified:</b> 2010-10-29</p>
8622 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
8623 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
8624 <p><b>Discussion:</b></p>
8626 What requirements does the standard place on equality comparisons between
8627 iterators that refer to elements of different containers. For example, if
8628 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
8629 Is it allowed to throw an exception?
8633 The standard appears to be silent on both questions.
8635 <p><i>[Sydney: The intention is that comparing two iterators from
8636 different containers is undefined, but it's not clear if we say that,
8637 or even whether it's something we should be saying in clause 23 or in
8638 clause 24. Intuitively we might want to say that equality is defined
8639 only if one iterator is reachable from another, but figuring out how
8640 to say it in any sensible way is a bit tricky: reachability is defined
8641 in terms of equality, so we can't also define equality in terms of
8652 Daniel volunteered to work on this.
8656 2009-09-20 Daniel provided wording.
8666 Leave as Open. Alisdair has volunteered to refine the wording.
8670 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
8676 <p><b>Rationale:</b></p>
8679 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
8683 <p><b>Proposed resolution:</b></p>
8685 Insert a new paragraph between 24.2 [iterator.requirements]/7+8:
8690 [..] The result of the application of functions in the library to invalid
8691 ranges is undefined.
8694 <p><ins>The result of directly or indirectly evaluating any comparison function
8695 or the binary - operator with two iterator values as arguments that
8697 from two different ranges <tt>r1</tt> and <tt>r2</tt> (including their past-the-end values) which
8698 are not subranges of one common range is undefined, unless explicitly
8699 described otherwise.</ins>
8710 <h3><a name="447"></a>447. Wrong template argument for time facets</h3>
8711 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8712 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2003-12-26 <b>Last modified:</b> 2010-10-29</p>
8713 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
8714 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8715 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
8716 <p><b>Discussion:</b></p>
8718 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
8720 <pre> time_get<char,InputIterator>
8721 time_get_byname<char,InputIterator>
8722 time_get<wchar_t,OutputIterator>
8723 time_get_byname<wchar_t,OutputIterator>
8727 The second argument to the last two should be InputIterator, not
8732 <p><b>Proposed resolution:</b></p>
8734 Change the second template argument to InputIterator.
8738 <p><b>Rationale:</b></p>
8746 <h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
8747 <p><b>Section:</b> 23.6.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8748 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
8749 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
8750 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8751 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
8752 <p><b>Discussion:</b></p>
8753 <p>map/multimap have:</p>
8755 <pre> iterator find(const key_type& x) const;
8756 const_iterator find(const key_type& x) const;
8760 which is consistent with the table of associative container requirements.
8761 But set/multiset have:
8763 <pre> iterator find(const key_type&) const;
8767 set/multiset should look like map/multimap, and honor the requirements
8768 table, in this regard.
8772 <p><b>Proposed resolution:</b></p>
8775 <p><b>Rationale:</b></p>
8783 <h3><a name="451"></a>451. Associative erase should return an iterator</h3>
8784 <p><b>Section:</b> 23.2.4 [associative.reqmts], 23.6 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8785 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
8786 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
8787 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
8788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8789 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
8790 <p><b>Discussion:</b></p>
8791 <p>map/multimap/set/multiset have:</p>
8792 <pre> void erase(iterator);
8793 void erase(iterator, iterator);
8796 <p>But there's no good reason why these can't return an iterator, as for
8797 vector/deque/list:</p>
8798 <pre> iterator erase(iterator);
8799 iterator erase(iterator, iterator);
8804 <p><b>Proposed resolution:</b></p>
8806 Informally: The table of associative container requirements, and the
8807 relevant template classes, should return an iterator designating the
8808 first element beyond the erased subrange.
8812 <p><b>Rationale:</b></p>
8820 <h3><a name="452"></a>452. locale::combine should be permitted to generate a named locale</h3>
8821 <p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8822 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
8823 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
8824 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8825 <p><b>Discussion:</b></p>
8826 <pre>template<class Facet>
8827 locale::combine(const locale&) const;
8830 is obliged to create a locale that has no name. This is overspecification
8831 and overkill. The resulting locale should follow the usual rules -- it
8832 has a name if the locale argument has a name and Facet is one of the
8837 Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
8838 c++std-lib-13443): agreed that it's overkill to say that the locale
8839 is obligated to be nameless. However, we also can't require it to
8840 have a name. At the moment, locale names are based on categories
8841 and not on individual facets. If a locale contains two different
8842 facets of different names from the same category, then this would
8843 not fit into existing naming schemes. We need to give
8844 implementations more freedom. Bill will provide wording.
8850 <p><b>Rationale:</b></p>
8851 <p>After further discussion the LWG decided to close this as NAD.
8852 The fundamental problem is that names right now are per-category,
8853 not per-facet. The <tt>combine</tt> member function works at the
8854 wrong level of granularity.</p>
8861 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
8862 <p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8863 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
8864 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
8865 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8866 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
8867 <p><b>Discussion:</b></p>
8868 <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
8871 <p>should be supplemented with the overload:</p>
8873 <pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
8877 Depending on the operating system, one of these forms is fundamental and
8878 the other requires an implementation-defined mapping to determine the
8882 <p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
8883 provide wording.]</i></p>
8887 In Toronto we noted that this is issue 5 from
8888 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
8892 How does this interact with the newly-defined character types, and how
8893 do we avoid interface explosion considering <tt>std::string</tt> overloads that
8894 were added? Propose another solution that is different than the
8895 suggestion proposed by PJP.
8898 Suggestion is to make a member template function for <tt>basic_string</tt> (for
8899 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
8900 <tt>const char*</tt> member.
8903 Goal is to do implicit conversion between character string literals to
8904 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
8907 Implementors are free to add specific overloads for non-char character
8912 Martin adds pre-Sophia Antipolis:
8917 Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
8927 Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
8928 usefully changed unless <tt>fstream</tt> is also changed; this also only handles
8929 <tt>wchar_t</tt> and not other character types.
8932 The TR2 filesystem library is a more complete solution, but is not available soon.
8937 Martin adds: please reference
8938 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
8939 problems and solutions.
8945 <p><b>Proposed resolution:</b></p>
8949 <pre>basic_filebuf<charT,traits>* open(
8951 ios_base::openmode mode );
8955 Effects: If is_open() != false, returns a null pointer.
8956 Otherwise, initializes the filebuf as required. It then
8957 opens a file, if possible, whose name is the NTBS s ("as if"
8958 by calling std::fopen(s,modstr)).</p>
8964 <pre>basic_filebuf<charT,traits>* open(
8966 ios_base::openmode mode );
8968 basic_filebuf<charT,traits>* open(
8970 ios_base::openmode mode );
8974 Effects: If is_open() != false, returns a null pointer.
8975 Otherwise, initializes the filebuf as required. It then
8976 opens a file, if possible, whose name is the NTBS s ("as if"
8977 by calling std::fopen(s,modstr)).
8978 For the second signature, the NTBS s is determined from the
8979 WCBS ws in an implementation-defined manner.
8983 (NOTE: For a system that "naturally" represents a filename
8984 as a WCBS, the NTBS s in the first signature may instead
8985 be mapped to a WCBS; if so, it follows the same mapping
8986 rules as the first argument to open.)
8992 <p><b>Rationale:</b></p>
8994 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
8995 this to Ready. The controversy was because the mapping between wide
8996 names and files in a filesystem is implementation defined. The
8997 counterargument, which most but not all LWG members accepted, is that
8998 the mapping between narrow files names and files is also
8999 implemenation defined.</p>
9001 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
9002 (1) Why just basic_filebuf, instead of also basic_fstream (and
9003 possibly other things too). (2) Why not also constructors that take
9004 std::basic_string? (3) We might want to wait until we see Beman's
9005 filesystem library; we might decide that it obviates this.]</i></p>
9015 Move again to Ready.
9018 There is a timing issue here. Since the filesystem library will not be
9019 in C++0x, this should be brought forward. This solution would remain
9020 valid in the context of the proposed filesystem.
9023 This issue has been kicking around for a while, and the wchar_t addition
9024 alone would help many users. Thus, we suggest putting this on the
9025 reflector list with an invitation for someone to produce proposed
9026 wording that covers basic_fstream. In the meantime, we suggest that the
9027 proposed wording be adopted as-is.
9030 If more of the Lillehammer questions come back, they should be
9031 introduced as separate issues.
9041 Some existing implementations provide overload already. Expected
9042 filesystem "path" object overloads neatly, without surprises; implying
9053 <h3><a name="458"></a>458. 24.1.5 contains unintended limitation for operator-</h3>
9054 <p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9055 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27 <b>Last modified:</b> 2010-10-29</p>
9056 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
9057 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9058 <p><b>Discussion:</b></p>
9060 In 24.1.5 [lib.random.access.iterators], table 76 the operational
9061 semantics for the expression "r -= n" are defined as "return r += -n".
9062 This means, that the expression -n must be valid, which is not the case
9067 Sydney: Possibly not a real problem, since difference type is required
9068 to be a signed integer type. However, the wording in the standard may
9069 be less clear than we would like.
9074 Post Summit Alisdair adds:
9080 This issue refers to a requirements table we have removed.
9083 The issue might now relate to 24.2.7 [random.access.iterators] p5.
9084 However, the rationale in the issue already recognises that the
9085 <tt>difference_type</tt> must be signed, so this really looks NAD.
9095 We agree with Alisdair's observations.
9109 Need to look at again without concepts.
9112 There was a question about this phrase in the discussion: "the
9113 expression -n must be valid, which is not the case for unsigned types."
9114 If n is an object ofthe iterator difference_type (eg ptrdiff_t), then it
9125 The group reviewed the wording in the draft and agreed that n is of
9126 difference type, the difference type is signed, and the current wording
9127 is correct. Moved to NAD.
9132 <p><b>Proposed resolution:</b></p>
9134 To remove this limitation, I suggest to change the
9135 operational semantics for this column to:
9137 <blockquote><pre> { Distance m = n;
9151 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
9152 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9153 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-03-16 <b>Last modified:</b> 2010-10-29</p>
9154 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
9155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9156 <p><b>Discussion:</b></p>
9157 <p>When parsing strings of wide-character digits, the standard
9158 requires the library to widen narrow-character "atoms" and compare
9159 the widened atoms against the characters that are being parsed.
9160 Simply narrowing the wide characters would be far simpler, and
9161 probably more efficient. The two choices are equivalent except in
9162 convoluted test cases, and many implementations already ignore the
9163 standard and use narrow instead of widen.</p>
9166 First, I disagree that using narrow() instead of widen() would
9167 necessarily have unfortunate performance implications. A possible
9168 implementation of narrow() that allows num_get to be implemented
9169 in a much simpler and arguably comparably efficient way as calling
9170 widen() allows, i.e. without making a virtual call to do_narrow every
9171 time, is as follows:
9174 <pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
9176 const unsigned wi = unsigned (wc);
9178 if (wi > UCHAR_MAX)
9179 return typeid (*this) == typeid (ctype<wchar_t>) ?
9180 dflt : do_narrow (wc, dflt);
9182 if (narrow_ [wi] < 0) {
9183 const char nc = do_narrow (wc, dflt);
9189 return char (narrow_ [wi]);
9194 Second, I don't think the change proposed in the issue (i.e., to use
9195 narrow() instead of widen() during Stage 2) would be at all
9196 drastic. Existing implementations with the exception of libstdc++
9197 currently already use narrow() so the impact of the change on programs
9198 would presumably be isolated to just a single implementation. Further,
9199 since narrow() is not required to translate alternate wide digit
9200 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> to
9201 their narrow equivalents (i.e., the portable source characters '0'
9202 through '9'), the change does not necessarily imply that these
9203 alternate digits would be treated as ordinary digits and accepted as
9204 part of numbers during parsing. In fact, the requirement in 22.4.1.1.2 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
9205 digit character, wc, to an ordinary digit in the basic source
9206 character set unless the expression
9207 (ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in
9208 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
9209 5.2.1, respectively) for charT of either char or wchar_t.
9212 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
9213 you're only trafficking in char and wchar_t we're only dealing with a
9214 stable character set, so you don't really need either 'widen' or
9215 'narrow': can just use literals. Finally, it's not even clear whether
9216 widen-vs-narrow is the right question; arguably we should be using
9217 codecvt instead.]</i></p>
9226 NAD. The standard is clear enough as written.
9231 <p><b>Proposed resolution:</b></p>
9232 <p>Change stage 2 so that implementations are permitted to use either
9233 technique to perform the comparison:</p>
9235 <li> call widen on the atoms and compare (either by using
9236 operator== or char_traits<charT>::eq) the input with
9237 the widened atoms, or</li>
9238 <li> call narrow on the input and compare the narrow input
9240 <li> do (1) or (2) only if charT is not char or wchar_t,
9241 respectively; i.e., avoid calling widen or narrow
9242 if it the source and destination types are the same</li>
9250 <h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
9251 <p><b>Section:</b> 3.6.3 [basic.start.term], 18.4 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9252 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23 <b>Last modified:</b> 2010-10-29</p>
9253 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9254 <p><b>Discussion:</b></p>
9256 3.6.3 Termination spells out in detail the interleaving of static
9257 destructor calls and calls to functions registered with atexit. To
9258 match this behavior requires intimate cooperation between the code
9259 that calls destructors and the exit/atexit machinery. The former
9260 is tied tightly to the compiler; the latter is a primitive mechanism
9261 inherited from C that traditionally has nothing to do with static
9262 construction and destruction. The benefits of intermixing destructor
9263 calls with atexit handler calls is questionable at best, and <i>very</i>
9264 difficult to get right, particularly when mixing third-party C++
9265 libraries with different third-party C++ compilers and C libraries
9266 supplied by still other parties.
9270 I believe the right thing to do is defer all static destruction
9271 until after all atexit handlers are called. This is a change in
9272 behavior, but one that is likely visible only to perverse test
9273 suites. At the very least, we should <i>permit</i> deferred destruction
9274 even if we don't require it.
9277 <p><i>[If this is to be changed, it should probably be changed by CWG.
9278 At this point, however, the LWG is leaning toward NAD. Implementing
9279 what the standard says is hard work, but it's not impossible and
9280 most vendors went through that pain years ago. Changing this
9281 behavior would be a user-visible change, and would break at least
9282 one real application.]</i></p>
9286 Batavia: Send to core with our recommendation that we should permit deferred
9287 destruction but not require it.
9292 Howard: The course of action recommended in Batavia would undo LWG
9293 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
9294 singleton". Search the net for "phoenix singleton atexit" to get a feel
9295 for the size of the adverse impact this change would have. Below is
9296 sample code which implements the phoenix singleton and would break if
9297 <tt>atexit</tt> is changed in this way:
9301 <blockquote><pre>#include <cstdlib>
9302 #include <iostream>
9303 #include <type_traits>
9304 #include <new>
9310 A& operator=(const A&);
9312 A() : alive_(true) {std::cout << "A()\n";}
9313 ~A() {alive_ = false; std::cout << "~A()\n";}
9317 std::cout << "A is alive\n";
9319 std::cout << "A is dead\n";
9323 void deallocate_resource();
9325 // This is the phoenix singleton pattern
9326 A& get_resource(bool create = true)
9328 static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf;
9332 if (a != (A*)&buf)
9334 a = ::new (&buf) A;
9335 std::atexit(deallocate_resource);
9341 a = (A*)&buf + 1;
9346 void deallocate_resource()
9348 get_resource(false);
9351 void use_A(const char* message)
9353 A& a = get_resource();
9354 std::cout << "Using A " << message << "\n";
9360 ~B() {use_A("from ~B()");}
9367 use_A("from main()");
9372 The correct output is:
9375 <blockquote><pre>A()
9386 Bellevue: Confirmed no interaction with <tt>quick_exit</tt>.
9387 Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
9388 as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
9389 Bill agrees issue is no longer serious, and accepts NAD.
9395 <p><b>Proposed resolution:</b></p>
9404 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
9405 <p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9406 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07 <b>Last modified:</b> 2010-10-29</p>
9407 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
9408 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9409 <p><b>Discussion:</b></p>
9412 TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
9413 member of auto_ptr (20.4.5.3/4) obsolete.
9417 The sole purpose of this obsolete conversion member is to enable copy
9418 initialization base from r-value derived (or any convertible types like
9421 <pre>#include <memory>
9422 using std::auto_ptr;
9427 auto_ptr<D> source();
9428 int sink(auto_ptr<B>);
9429 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
9433 The excellent analysis of conversion operations that was given in the final
9435 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
9436 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
9437 wrong and actually comes to forbid the loophole that was exploited by the
9442 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
9443 ever allowed this case. This is probably because it requires 3 user defined
9444 conversions and in fact current compilers conform to DR #84.
9448 I was surprised to discover that the obsolete conversion member actually has
9449 negative impact of the copy initialization base from l-value derived
9451 <pre>auto_ptr<D> dp;
9452 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
9456 I'm sure that the original intention was allowing this initialization using
9457 the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
9458 since in this copy initialization it's merely user defined conversion (UDC)
9459 and the obsolete conversion member is UDC with the same rank (for the early
9460 overloading stage) there is an ambiguity between them.
9464 Removing the obsolete member will have impact on code that explicitly
9467 <pre>int y = sink(source().operator auto_ptr<B>());
9471 IMHO no one ever wrote such awkward code and the reasonable workaround for
9474 <pre>int y = sink( auto_ptr<B>(source()) );
9478 I was even more surprised to find out that after removing the obsolete
9479 conversion member the initialization was still ill-formed:
9480 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
9484 This copy initialization semantically requires copy constructor which means
9485 that both template conversion constructor and the auto_ptr_ref conversion
9486 member (20.4.5.3/3) are required which is what was explicitly forbidden in
9487 DR #84. This is a bit amusing case in which removing ambiguity results with
9492 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
9494 <pre>int f(auto_ptr<B>, std::string);
9495 auto_ptr<B> source2();
9497 // string constructor throws while auto_ptr_ref
9498 // "holds" the pointer
9499 int x4 = f(source2(), "xyz"); // #4
9503 The theoretic execution sequence that will cause a leak:
9506 <li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li>
9507 <li>call string::string(char const*) and throw</li>
9511 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
9512 returns auto_ptr_ref<Y> that holds *this and this is another defect since
9513 the type of *this is auto_ptr<X> where X might be different from Y. Several
9514 library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
9515 is much more reasonable. Other vendor implemented auto_ptr_ref as
9516 defectively required and it results with awkward and catastrophic code:
9517 int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
9522 Dave Abrahams noticed that there is no specification saying that
9523 auto_ptr_ref copy constructor can't throw.
9527 My proposal comes to solve all the above issues and significantly simplify
9528 auto_ptr implementation. One of the fundamental requirements from auto_ptr
9529 is that it can be constructed in an intuitive manner (i.e. like ordinary
9530 pointers) but with strict ownership semantics which yield that source
9531 auto_ptr in initialization must be non-const. My idea is to add additional
9532 constructor template with sole propose to generate ill-formed, diagnostic
9533 required, instance for const auto_ptr arguments during instantiation of
9534 declaration. This special constructor will not be instantiated for other
9535 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
9536 in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
9537 legitimate since the actual argument can't be const yet non const r-value
9542 This implementation technique makes the "private auxiliary class"
9543 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
9544 GCC and VC) consume the new implementation as expected and allow all
9545 intuitive initialization and assignment cases while rejecting illegal cases
9546 that involve const auto_ptr arguments.
9549 <p>The proposed auto_ptr interface:</p>
9551 <pre>namespace std {
9552 template<class X> class auto_ptr {
9554 typedef X element_type;
9556 // 20.4.5.1 construct/copy/destroy:
9557 explicit auto_ptr(X* p=0) throw();
9558 auto_ptr(auto_ptr&) throw();
9559 template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
9560 auto_ptr& operator=(auto_ptr&) throw();
9561 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
9562 ~auto_ptr() throw();
9564 // 20.4.5.2 members:
9565 X& operator*() const throw();
9566 X* operator->() const throw();
9567 X* get() const throw();
9568 X* release() throw();
9569 void reset(X* p=0) throw();
9572 template<class U>
9573 auto_ptr(U& rhs, typename
9574 unspecified_error_on_const_auto_ptr<U>::type = 0);
9580 One compliant technique to implement the unspecified_error_on_const_auto_ptr
9581 helper class is using additional private auto_ptr member class template like
9584 <pre>template<typename T> struct unspecified_error_on_const_auto_ptr;
9586 template<typename T>
9587 struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
9588 { typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
9592 There are other techniques to implement this helper class that might work
9593 better for different compliers (i.e. better diagnostics) and therefore I
9594 suggest defining its semantic behavior without mandating any specific
9595 implementation. IMO, and I didn't found any compiler that thinks otherwise,
9596 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
9597 verifying this with core language experts.
9600 <p><b>Further changes in standard text:</b></p>
9601 <p>Remove section 20.4.5.3</p>
9603 <p>Change 20.4.5/2 to read something like:
9604 Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
9605 ill-formed declaration that will require unspecified diagnostic.</p>
9607 <p>Change 20.4.5.1/4,5,6 to read:</p>
9609 <pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre>
9610 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
9611 <p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p>
9612 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
9614 <p>Change 20.4.5.1/10</p>
9615 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
9618 10 Requires: Y* can be implicitly converted to X*. The expression delete
9619 get() is well formed.
9622 <p>LWG TC DR #127 is obsolete.</p>
9625 Notice that the copy constructor and copy assignment operator should remain
9626 as before and accept non-const auto_ptr& since they have effect on the form
9627 of the implicitly declared copy constructor and copy assignment operator of
9628 class that contains auto_ptr as member per 12.8/5,10:
9631 // implicit X(X&)
9632 // implicit X& operator=(X&)
9633 auto_ptr<D> aptr_;
9638 In most cases this indicates about sloppy programming but preserves the
9639 current auto_ptr behavior.
9643 Dave Abrahams encouraged me to suggest fallback implementation in case that
9644 my suggestion that involves removing of auto_ptr_ref will not be accepted.
9645 In this case removing the obsolete conversion member to auto_ptr<Y> and
9646 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
9647 cases. The two constructors that I suggested will co exist with the current
9648 members but will make auto_ptr_ref obsolete in initialization contexts.
9649 auto_ptr_ref will be effective in assignment contexts as suggested in DR
9650 #127 and I can't see any serious exception safety issues in those cases
9651 (although it's possible to synthesize such). auto_ptr_ref<X> semantics will
9652 have to be revised to say that it strictly holds pointer of type X and not
9653 reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
9654 constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
9655 from r-value derived to base).
9658 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
9659 want to fix auto_ptr for C++-0x, or remove it and replace it with
9660 move_ptr and unique_ptr.]</i></p>
9664 Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases
9665 and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended
9671 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
9681 This is a complicated issue, so we agreed to defer discussion until
9682 later in the week so that interested parties can read up on it.
9686 209-10-04 Daniel adds:
9692 I suggest to close this issue as NAD. The reasons are two-fold: First, the
9693 suggested proposed resolution uses no longer appropriate language means
9694 to solve this issue, which has the effect that the recommended resolution is
9695 another - but better - form of hack. Second, either following the suggested
9696 resolution or the now more natural alternative via the added member set
9699 <blockquote><pre>template<class Y> auto_ptr(auto_ptr<Y>&&) throw();
9700 template<class Y> auto_ptr& operator=(auto_ptr<Y>&&) throw();
9704 would still have a non-zero probability to break user-code that actively
9705 references <tt>auto_ptr_ref</tt>. This risk seems to indicate that a
9706 decision which would not touch the current spec of <tt>auto_ptr</tt> at
9707 all (but deprecating it) and instead recommending to use
9708 <tt>unique_ptr</tt> for new code instead might have the best
9709 cost-benefit ratio. IMO the current solution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a> can
9710 be considered as an active user-support for this transition.
9720 Mark as NAD. Alisdair will open a new issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>) with
9721 proposed wording to handle <tt>auto_ptr_ref</tt>.
9726 <p><b>Proposed resolution:</b></p>
9728 Change the synopsis in D.12.1 [auto.ptr]:
9731 <blockquote><pre>namespace std {
9732 <del>template <class Y> struct auto_ptr_ref {};</del>
9734 <ins>// exposition only</ins>
9735 <ins>template <class T> struct constant_object;</ins>
9737 <ins>// exposition only</ins>
9738 <ins>template <class T></ins>
9739 <ins>struct cannot_transfer_ownership_from</ins>
9740 <ins>: constant_object<T> {};</ins>
9742 template <class X> class auto_ptr {
9744 typedef X element_type;
9746 // D.9.1.1 construct/copy/destroy:
9747 explicit auto_ptr(X* p =0) throw();
9748 auto_ptr(auto_ptr&) throw();
9749 template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw();
9750 auto_ptr& operator=(auto_ptr&) throw();
9751 template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw();
9752 <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del>
9753 ~auto_ptr() throw();
9756 X& operator*() const throw();
9757 X* operator->() const throw();
9758 X* get() const throw();
9759 X* release() throw();
9760 void reset(X* p =0) throw();
9762 <del>// D.9.1.3 conversions:</del>
9763 <del>auto_ptr(auto_ptr_ref<X>) throw();</del>
9764 <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del>
9765 <del>template<class Y> operator auto_ptr<Y>() throw();</del>
9767 <ins>// exposition only</ins>
9768 <ins>template<class U></ins>
9769 <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins>
9772 template <> class auto_ptr<void>
9775 typedef void element_type;
9782 Remove D.12.1.3 [auto.ptr.conv].
9786 Change D.12.1 [auto.ptr], p3:
9790 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
9791 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
9792 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
9793 destination. If more than one <tt>auto_ptr</tt> owns the same object at
9794 the same time the behavior of the program is undefined. <ins>Templates
9795 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
9796 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
9797 For any types <tt>X</tt> and <tt>Y</tt>, initializing
9798 <tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is
9799 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
9800 <tt>auto_ptr</tt> include providing temporary exception-safety for
9801 dynamically allocated memory, passing ownership of dynamically allocated
9802 memory to a function, and returning dynamically allocated memory from a
9803 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
9804 and <tt>Assignable</tt> requirements for Standard Library container
9805 elements and thus instantiating a Standard Library container with an
9806 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
9810 Change D.12.1.1 [auto.ptr.cons], p5:
9814 <pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw();
9818 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
9821 <i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
9824 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
9830 Change D.12.1.1 [auto.ptr.cons], p10:
9834 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw();
9838 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
9839 The expression <tt>delete get()</tt> is well formed.
9842 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
9845 <i>Returns:</i> <tt>*this</tt>.
9856 <h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
9857 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9858 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-06-10 <b>Last modified:</b> 2010-10-29</p>
9859 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
9860 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9861 <p><b>Discussion:</b></p>
9863 Today, my colleagues and me wasted a lot of time. After some time, I
9864 found the problem. It could be reduced to the following short example:
9867 <pre> #include <string>
9868 int main() { std::string( 0 ); }
9871 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
9872 Comeau online) compile the above without errors or warnings! The
9873 programs (at least for the GCC) resulted in a SEGV.</p>
9875 <p>I know that the standard explicitly states that the ctor of string
9876 requires a char* which is not zero. STLs could easily detect the above
9877 case with a private ctor for basic_string which takes a single 'int'
9878 argument. This would catch the above code at compile time and would not
9879 ambiguate any other legal ctors.</p>
9881 <p><i>[Redmond: No great enthusiasm for doing this. If we do,
9882 however, we want to do it for all places that take <tt>charT*</tt>
9883 pointers, not just the single-argument constructor. The other
9884 question is whether we want to catch this at compile time (in which
9885 case we catch the error of a literal 0, but not an expression whose
9886 value is a null pointer), at run time, or both.
9887 Recommend NAD. Relegate this functionality to debugging implementations.]</i></p>
9891 Post Summit: Alisdair requests this be re-opened as several new language facilities are
9892 designed to solve exactly this kind of problem.
9901 We are unable to achieve consensus on an approach to a resolution.
9902 There is some sentiment for treating this as a QOI matter.
9904 that when <tt>string</tt> is brought into the concepts world,
9905 this issue might be addressed in that context.
9915 We considered three options:
9919 <li>The proposed resolution.</li>
9921 <li>Interpret a null pointer as the empty string.</li>
9925 The consensus was NAD.
9931 <p><b>Proposed resolution:</b></p>
9933 Add to the synopsis in 21.4 [basic.string]
9936 <blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins>
9944 <h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
9945 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9946 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
9947 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
9948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9949 <p><b>Discussion:</b></p>
9952 The standard doesn't prohibit the destructors (or any other special
9953 functions) of containers' elements invoked from a member function
9954 of the container from "recursively" calling the same (or any other)
9955 member function on the same container object, potentially while the
9956 container is in an intermediate state, or even changing the state
9957 of the container object while it is being modified. This may result
9958 in some surprising (i.e., undefined) behavior.
9961 <p>Read email thread starting with c++std-lib-13637 for more.</p>
9965 <p><b>Proposed resolution:</b></p>
9967 <p>Add to Container Requirements the following new paragraph:</p>
9969 <pre> Unless otherwise specified, the behavior of a program that
9970 invokes a container member function f from a member function
9971 g of the container's value_type on a container object c that
9972 called g from its mutating member function h, is undefined.
9973 I.e., if v is an element of c, directly or indirectly calling
9974 c.h() from v.g() called from c.f(), is undefined.
9977 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
9978 issue, not clause 23. We get the same issue, for example, if we
9979 try to destroy a stream from one of the stream's callback functions.]</i></p>
9984 <p><b>Rationale:</b></p>
9986 Recommend NAD. We agree this is an issue, but not a defect.
9987 We believe that there is no wording we can put in the standard
9988 that will cover all cases without introducing unfortunate
9997 <h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
9998 <p><b>Section:</b> 25.4.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9999 <b>Submitter:</b> Prateek R Karandikar <b>Opened:</b> 2004-06-30 <b>Last modified:</b> 2010-10-29</p>
10000 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
10001 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
10002 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
10003 <p><b>Discussion:</b></p>
10005 There is no "Returns:" clause for std::equal_range, which returns non-void.
10009 <p><b>Proposed resolution:</b></p>
10012 <p><b>Rationale:</b></p>
10013 <p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
10021 <h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
10022 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10023 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-09 <b>Last modified:</b> 2010-10-29</p>
10024 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
10025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10026 <p><b>Discussion:</b></p>
10028 <p>24.1/3 says:</p>
10030 Forward iterators satisfy all the requirements of the input and
10031 output iterators and can be used whenever either kind is specified
10035 The problem is that satisfying the requirements of output iterator
10036 means that you can always assign *something* into the result of
10037 dereferencing it. That makes almost all non-mutable forward
10038 iterators non-conforming. I think we need to sever the refinement
10039 relationship between forward iterator and output iterator.
10042 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p>
10046 <p><b>Proposed resolution:</b></p>
10049 <p><b>Rationale:</b></p>
10050 <p>Yes, 24.1/3 does say that. But it's introductory material. The
10051 precise specification is in 24.1.3, and the requrements table there is
10052 right. We don't need to fine-tune introductory wording. (Especially
10053 since this wording is likely to be changed as part of the iterator
10061 <h3><a name="477"></a>477. Operator-> for const forward iterators</h3>
10062 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
10063 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11 <b>Last modified:</b> 2010-10-29</p>
10064 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
10065 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
10066 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
10067 <p><b>Discussion:</b></p>
10069 The Forward Iterator requirements table contains the following:
10071 <pre> expression return type operational precondition
10073 ========== ================== =========== ==========================
10074 a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined.
10075 otherwise const U&
10077 r->m U& (*r).m pre: (*r).m is well-defined.
10081 The first line is exactly right. The second line is wrong. Basically
10082 it implies that the const-ness of the iterator affects the const-ness
10083 of referenced members. But Paragraph 11 of [lib.iterator.requirements] says:
10087 In the following sections, a and b denote values of type const X, n
10088 denotes a value of the difference type Distance, u, tmp, and m
10089 denote identifiers, r denotes a value of X&, t denotes a value of
10090 value type T, o denotes a value of some type that is writable to
10091 the output iterator.
10094 <p>AFAICT if we need the second line at all, it should read the same
10095 as the first line.</p>
10097 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
10100 <p><b>Proposed resolution:</b></p>
10103 <p><b>Rationale:</b></p>
10104 <p>The LWG agrees that this is a real problem. Marked as a DUP
10105 because the LWG chose to adopt the solution proposed in
10106 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
10114 <h3><a name="479"></a>479. Container requirements and placement new</h3>
10115 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
10116 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2004-08-01 <b>Last modified:</b> 2010-10-29</p>
10117 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
10118 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
10119 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a></p>
10120 <p><b>Discussion:</b></p>
10121 <p>Nothing in the standard appears to make this program ill-formed:</p>
10124 void* operator new( size_t s ) { return ::operator new( s ); }
10125 // NOTE: this hides in-place and nothrow new
10130 v.push_back( C() );
10134 <p>Is that intentional? We should clarify whether or not we intended
10135 to require containers to support types that define their own special
10136 versions of <tt>operator new</tt>.</p>
10139 Lillehammer: A container will definitely never use this overridden
10140 operator new, but whether it will fail to compile is unclear from the
10141 standard. Are containers supposed to use qualified or unqualified
10142 placement new? 20.4.1.1 is somewhat relevant, but the standard
10143 doesn't make it completely clear whether containers have to use
10144 Allocator::construct(). If containers don't use it, the details of how
10145 containers use placement new are unspecified. That is the real bug,
10146 but it needs to be fixed as part of the allocator overhaul. Weak
10147 support that the eventual solution should make this code well formed.
10153 <p><b>Proposed resolution:</b></p>
10162 <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
10163 <p><b>Section:</b> X [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10164 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2004-08-19 <b>Last modified:</b> 2010-10-29</p>
10165 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
10166 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10167 <p><b>Discussion:</b></p>
10168 <p>The classes std::unary_function and std::binary_function are both
10169 designed to be inherited from but contain no virtual functions. This
10170 makes it too easy for a novice programmer to write code like
10171 binary_function<int, int, int> *p = new plus<int>; delete p;</p>
10173 <p>There are two common ways to prevent this source of undefined
10174 behavior: give the base class a public virtual destructor, or give it
10175 a protected nonvirtual destructor. Since unary_function and
10176 binary_function have no other virtual functions, (note in particular
10177 the absence of an operator()() ), it would cost too much to give them
10178 public virtual destructors. Therefore, they should be given protected
10179 nonvirtual destructors.</p>
10182 <p><b>Proposed resolution:</b></p>
10183 <p>Change Paragraph 20.3.1 of the Standard from</p>
10184 <pre> template <class Arg, class Result>
10185 struct unary_function {
10186 typedef Arg argument_type;
10187 typedef Result result_type;
10190 template <class Arg1, class Arg2, class Result>
10191 struct binary_function {
10192 typedef Arg1 first_argument_type;
10193 typedef Arg2 second_argument_type;
10194 typedef Result result_type;
10199 <pre> template <class Arg, class Result>
10200 struct unary_function {
10201 typedef Arg argument_type;
10202 typedef Result result_type;
10204 ~unary_function() {}
10207 template <class Arg1, class Arg2, class Result>
10208 struct binary_function {
10209 typedef Arg1 first_argument_type;
10210 typedef Arg2 second_argument_type;
10211 typedef Result result_type;
10213 ~binary_function() {}
10218 <p><b>Rationale:</b></p>
10219 <p>The LWG doesn't believe the existing definition causes anybody any
10227 <h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
10228 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10229 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-08-30 <b>Last modified:</b> 2010-10-29</p>
10230 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
10231 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10232 <p><b>Discussion:</b></p>
10234 The standard says that unique(first, last) "eliminates all but the
10235 first element from every consecutive group of equal elements" in
10236 [first, last) and returns "the end of the resulting range". So a
10237 postcondition is that [first, result) is the same as the old [first,
10238 last) except that duplicates have been eliminated.
10241 <p>What postconditions are there on the range [result, last)? One
10242 might argue that the standard says nothing about those values, so
10243 they can be anything. One might also argue that the standard
10244 doesn't permit those values to be changed, so they must not be.
10245 Should the standard say something explicit one way or the other?</p>
10249 <p><b>Proposed resolution:</b></p>
10254 <p><b>Rationale:</b></p>
10255 <p>We don't want to make many guarantees about what's in [result,
10256 end). Maybe we aren't being quite explicit enough about not being
10257 explicit, but it's hard to think that's a major problem.</p>
10264 <h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
10265 <p><b>Section:</b> 25.2 [alg.nonmodifying], 25.3 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
10266 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2004-09-20 <b>Last modified:</b> 2010-10-29</p>
10267 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
10268 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
10269 <p><b>Discussion:</b></p>
10270 <p>c++std-lib-14262</p>
10272 <p>[lib.alg.find] requires T to be EqualityComparable:</p>
10274 <pre>template <class InputIterator, class T>
10275 InputIterator find(InputIterator first, InputIterator last,
10276 const T& value);
10280 However the condition being tested, as specified in the Effects
10281 clause, is actually *i == value, where i is an InputIterator.
10285 The two clauses are in agreement only if the type of *i is T, but this
10286 isn't necessarily the case. *i may have a heterogeneous comparison
10287 operator that takes a T, or a T may be convertible to the type of *i.
10290 <p>Further discussion (c++std-lib-14264): this problem affects a
10291 number of algorithsm in clause 25, not just <tt>find</tt>. We
10292 should try to resolve this problem everywhere it appears.</p>
10295 <p><b>Proposed resolution:</b></p>
10297 <p>[lib.alg.find]:</p>
10299 Remove [lib.alg.find]/1.
10302 <p>[lib.alg.count]:</p>
10304 Remove [lib.alg.count]/1.
10307 <p>[lib.alg.search]:</p>
10309 Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
10312 <p>[lib.alg.replace]:</p>
10316 Remove [lib.alg.replace]/1.
10317 Replace [lb.alg.replace]/2 with:
10321 For every iterator i in the range [first, last) for which *i == value
10322 or pred(*i) holds perform *i = new_value.
10326 Remove the first sentence of /4.
10327 Replace the beginning of /5 with:
10331 For every iterator i in the range [result, result + (last -
10332 first)), assign to *i either...
10335 <p>(Note the defect here, current text says assign to i, not *i).</p>
10338 <p>[lib.alg.fill]:</p>
10342 Remove "Type T is Assignable (23.1), " from /1.
10347 For every iterator i in the range [first, last) or [first, first + n),
10348 perform *i = value.
10352 <p>[lib.alg.remove]:</p>
10355 Remove the first sentence of /6.
10360 <p><b>Rationale:</b></p>
10361 <p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
10369 <h3><a name="484"></a>484. Convertible to T</h3>
10370 <p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
10371 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16 <b>Last modified:</b> 2010-10-29</p>
10372 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
10373 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
10374 <p><b>Discussion:</b></p>
10375 <p>From comp.std.c++:</p>
10378 I note that given an input iterator a for type T,
10379 then *a only has to be "convertable to T", not actually of type T.
10382 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
10383 While I assume it is the obvious definition (an implicit conversion), I
10384 can't find an exact definition. Is there one?</p>
10386 <p>Slightly more worryingly, there doesn't seem to be any restriction on
10387 the this type, other than it is "convertable to T". Consider two input
10388 iterators a and b. I would personally assume that most people would
10389 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
10390 the standard requires that, and that whatever type *a is (call it U)
10391 could have == defined on it with totally different symantics and still
10392 be a valid inputer iterator.</p>
10394 <p>Is this a correct reading? When using input iterators should I write
10395 T(*a) all over the place to be sure that the object i'm using is the
10396 class I expect?</p>
10398 <p>This is especially a nuisance for operations that are defined to be
10399 "convertible to bool". (This is probably allowed so that
10400 implementations could return say an int and avoid an unnessary
10401 conversion. However all implementations I have seen simply return a
10402 bool anyway. Typical implemtations of STL algorithms just write
10403 things like <tt>while(a!=b && *a!=0)</tt>. But strictly
10404 speaking, there are lots of types that are convertible to T but
10405 that also overload the appropriate operators so this doesn't behave
10408 <p>If we want to make code like this legal (which most people seem to
10409 expect), then we'll need to tighten up what we mean by "convertible
10412 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
10413 well-defined in core. The second part is basically about pathological
10414 overloads. It's a minor problem but a real one. So leave open for
10415 now, hope we solve it as part of iterator redesign.]</i></p>
10419 2009-07-28 Reopened by Alisdair. No longer solved by concepts.
10424 2009-10 Santa Cruz:
10429 Mark as NAD Future. We agree there's an issue, but there is no
10430 proposed solution at this time and this will be solved by concepts in
10436 <p><b>Proposed resolution:</b></p>
10439 <p><b>Rationale:</b></p>
10447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
10457 <h3><a name="485"></a>485. output iterator insufficiently constrained</h3>
10458 <p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
10459 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13 <b>Last modified:</b> 2010-10-29</p>
10460 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
10461 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
10462 <p><b>Discussion:</b></p>
10464 The note on 24.1.2 Output iterators insufficiently limits what can be
10465 performed on output iterators. While it requires that each iterator is
10466 progressed through only once and that each iterator is written to only
10467 once, it does not require the following things:</p>
10469 <p>Note: Here it is assumed that x is an output iterator of type X which
10470 has not yet been assigned to.</p>
10472 <p>a) That each value of the output iterator is written to:
10473 The standard allows:
10478 b) That assignments to the output iterator are made in order
10479 X a(x); ++a; *a=1; *x=2; is allowed
10483 c) Chains of output iterators cannot be constructed:
10484 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
10485 wording (I believe) x,a,b,c could be written to in any order.
10488 <p>I do not believe this was the intension of the standard?</p>
10489 <p><i>[Lillehammer: Real issue. There are lots of constraints we
10490 intended but didn't specify. Should be solved as part of iterator
10500 Bill provided wording according to consensus.
10504 2009-07-21 Alisdair requests change from Review to Open. See thread starting
10505 with c++std-lib-24459 for discussion.
10510 2009-10 Santa Cruz:
10515 Modified wording. Set to Review.
10519 2009-10 Santa Cruz:
10524 Move to Ready after looking at again in a larger group in Santa Cruz.
10533 Moved to NAD Editorial. Rationale added below.
10538 <p><b>Rationale:</b></p>
10544 <p><b>Proposed resolution:</b></p>
10546 Change Table 101
\97 Output iterator requirements in 24.2.4 [output.iterators]:
10550 <caption>Table 101
\97 Output iterator requirements</caption>
10552 <th>Expression</th>
10553 <th>Return type</th>
10554 <th>Operational semantics</th>
10555 <th>Assertion/note pre-/post-condition</th>
10569 <tt>a = t</tt> is equivalent to <tt>X(a) = t</tt>. note: a destructor is assumed.
10575 <tt>X u(a);</tt><br>
10601 Post: <tt>r</tt> is not required to be dereferenceable. <tt>r</tt> is incrementable.
10617 <tt>&r == &++r</tt>
10619 Post: <tt>r</tt> is dereferenceable, unless otherwise specified. <tt>r</tt> is not required to be incrementable.
10629 convertible to <tt>const X&</tt>
10632 <tt>{X tmp = r;<br>++r;<br>return tmp;}</tt>
10636 Post: <tt>r</tt> is dereferenceable, unless otherwise specified. <tt>r</tt> is not required to be incrementable.
10664 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
10665 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
10666 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-10-13 <b>Last modified:</b> 2010-10-29</p>
10667 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
10668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
10669 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
10670 <p><b>Discussion:</b></p>
10671 <p>A straightforward implementation of these algorithms does not need to
10675 <p><b>Proposed resolution:</b></p>
10676 <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
10679 <p><b>Rationale:</b></p>
10687 <h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
10688 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10689 <b>Submitter:</b> Dhruv Matani <b>Opened:</b> 2004-10-17 <b>Last modified:</b> 2010-10-29</p>
10690 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
10691 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10692 <p><b>Discussion:</b></p>
10694 The standard's version of allocator::construct(pointer,
10695 const_reference) severely limits what you can construct using this
10696 function. Say you can construct a socket from a file descriptor. Now,
10697 using this syntax, I first have to manually construct a socket from
10698 the fd, and then pass the constructed socket to the construct()
10699 function so it will just to an uninitialized copy of the socket I
10700 manually constructed. Now it may not always be possible to copy
10701 construct a socket eh! So, I feel that the changes should go in the
10702 allocator::construct(), making it:
10704 <pre> template<typename T>
10706 template<typename T1>
10707 void construct(pointer T1 const& rt1);
10712 Now, the ctor of the class T which matches the one that takes a T1 can
10713 be called! Doesn't that sound great?
10717 <p><b>Proposed resolution:</b></p>
10720 <p><b>Rationale:</b></p>
10721 <p>NAD. STL uses copying all the time, and making it possible for
10722 allocators to construct noncopyable objects is useless in the
10723 absence of corresponding container changes. We might consider this
10724 as part of a larger redesign of STL.</p>
10731 <h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
10732 <p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10733 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2010-10-29</p>
10734 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
10735 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10736 <p><b>Discussion:</b></p>
10737 <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
10738 behavior of the mutating sequence operations std::remove and
10739 std::remove_if. However, the wording does not reflect the intended
10740 behavior [Note: See definition of intended behavior below] of these
10741 algorithms, as it is known to the C++ community [1].
10746 <p>1) Analysis of current wording:</p>
10749 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
10751 <p>Current wording says:
10752 "Effects: Eliminates all the elements referred to by iterator i in the
10753 range [first, last) for which the following corresponding conditions
10754 hold: *i == value, pred(*i) != false."</p>
10757 This sentences expresses specifically that all elements denoted by the
10758 (original) range [first, last) for which the corresponding condition
10759 hold will be eliminated. Since there is no formal definition of the term
10760 "eliminate" provided, the meaning of "eliminate" in everyday language
10761 implies that as postcondition, no element in the range denoted by
10762 [first, last) will hold the corresponding condition on reiteration over
10763 the range [first, last).
10767 However, this is neither the intent [Note: See definition of intended
10768 behavior below] nor a general possible approach. It can be easily proven
10769 that if all elements of the original range[first, last) will hold the
10770 condition, it is not possible to substitute them by an element for which
10771 the condition will not hold.
10775 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
10778 Current wording says:
10779 "Returns: The end of the resulting range."
10783 The resulting range is not specified. In combination with 25.2.7
10784 [lib.alg.remove], paragraph 2, the only reasonable interpretation of
10785 this so-called resulting range is the range [first,last) - thus
10786 returning always the ForwardIterator 'last' parameter.
10791 25.2.7 [lib.alg.remove], paragraph 4:
10795 Current wording says:
10796 "Notes: Stable: the relative order of the elements that are not removed
10797 is the same as their relative order in the original range"
10801 This sentences makes use of the term "removed", which is neither
10802 specified, nor used in a previous paragraph (which uses the term
10803 "eliminate"), nor unamgiuously separated from the name of the algorithm.
10807 <p>2) Description of intended behavior:</p>
10810 For the rest of this Defect Report, it is assumed that the intended
10811 behavior was that all elements of the range [first, last) which do not
10812 hold the condition *i == value (std::remove) or pred(*i) != false
10813 (std::remove_if)], call them s-elements [Note: s...stay], will be placed
10814 into a contiguous subrange of [first, last), denoted by the iterators
10815 [first, return value). The number of elements in the resulting range
10816 [first, return value) shall be equal to the number of s-elements in the
10817 original range [first, last). The relative order of the elements in the
10818 resulting subrange[first, return value) shall be the same as the
10819 relative order of the corresponding elements in the original range. It
10820 is undefined whether any elements in the resulting subrange [return
10821 value, last) will hold the corresponding condition, or not.
10825 All implementations known to the author of this Defect Report comply
10826 with this intent. Since the intent of the behavior (contrary to the
10827 current wording) is also described in various utility references serving
10828 the C++ community [1], it is not expected that fixing the paragraphs
10829 will influence current code - unless the code relies on the behavior as
10830 it is described by current wording and the implementation indeed
10831 reflects the current wording, and not the intent.
10836 <p>3) Proposed fixes:</p>
10839 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
10842 "Effect: Places all the elements referred to by iterator i in the range
10843 [first, last) for which the following corresponding conditions hold :
10844 !(*i == value), pred(*i) == false into the subrange [first, k) of the
10845 original range, where k shall denote a value of type ForwardIterator. It
10846 is undefined whether any elements in the resulting subrange [k, last)
10847 will hold the corresponding condition, or not."
10850 <p>Comments to the new wording:</p>
10853 a) "Places" has no special meaning, and the everyday language meaning
10855 b) The corresponding conditions were negated compared to the current
10856 wording, becaue the new wording requires it.
10857 c) The wording "of the original range" might be redundant, since any
10858 subrange starting at 'first' and containing no more elements than the
10859 original range is implicitly a subrange of the original range [first,
10861 d) The iterator k was introduced instead of "return value" in order to
10862 avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
10863 denote a value of type ForwardIterator" might be redundant, because it
10864 follows implicitly by 25.2.7/3.
10865 e) "Places" does, in the author's opinion, explicitly forbid duplicating
10866 any element holding the corresponding condition in the original range
10867 [first, last) within the resulting range [first, k). If there is doubt
10868 this term might be not unambiguous regarding this, it is suggested that
10869 k is specified more closely by the following wording: "k shall denote a
10870 value of type ForwardIterator [Note: see d)] so that k - first is equal
10871 to the number of elements in the original range [first, last) for which
10872 the corresponding condition did hold". This could also be expressed as a
10873 separate paragraph "Postcondition:"
10874 f) The senctence "It is undefined whether any elements in the resulting
10875 subrange [k, last) will hold the corresponding condition, or not." was
10876 added consciously so the term "Places" does not imply if the original
10877 range [first, last) contains n elements holding the corresponding
10878 condition, the identical range[first, last) will also contain exactly n
10879 elements holding the corresponding condition after application of the
10884 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
10886 "Returns: The iterator k."
10890 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
10892 "Notes: Stable: the relative order of the elements that are placed into
10893 the subrange [first, return value) shall be the same as their relative
10894 order was in the original range [first, last) prior to application of
10899 Comments to the new wording:
10903 a) the wording "was ... prior to application of the algorithm" is used
10904 to explicitly distinguish the original range not only by means of
10905 iterators, but also by a 'chronological' factor from the resulting range
10906 [first, return value). It might be redundant.
10911 The wording of these references is not always unambiguous, and provided
10912 examples partially contradict verbal description of the algorithms,
10913 because the verbal description resembles the problematic wording of
10914 ISO/IEC 14882:2003.
10918 <p><b>Proposed resolution:</b></p>
10921 <p><b>Rationale:</b></p>
10922 <p>The LWG believes that the standard is sufficiently clear, and that
10923 there is no evidence of any real-world confusion about this point.</p>
10930 <h3><a name="490"></a>490. std::unique wrongly specified</h3>
10931 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10932 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2010-10-29</p>
10933 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
10934 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10935 <p><b>Discussion:</b></p>
10936 <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
10937 behavior of the mutating sequence operation std::unique. However, the
10938 wording does not reflect the intended behavior [Note: See definition of
10939 intended behavior below] of these algorithms, as it is known to the C++
10944 <p>1) Analysis of current wording:</p>
10947 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
10950 Current wording says:
10951 "Effects: Eliminates all but the first element from every consecutive
10952 group of equal elements referred to by the iterator i in the range
10953 [first, last) for which the following corresponding conditions hold: *i
10954 == *(i - 1) or pred(*i, *(i -1)) != false"
10958 This sentences expresses specifically that all elements denoted by the
10959 (original) range [first, last) which are not but the first element from
10960 a consecutive group of equal elements (where equality is defined as *i
10961 == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
10962 them r-elements [Note: r...remove], will be eliminated. Since there is
10963 no formal definition of the term "eliminate" provided, it is undefined
10964 how this "elimination" takes place. But the meaning of "eliminate" in
10965 everyday language seems to disallow explicitly that after application of
10966 the algorithm, any r-element will remain at any position of the range
10971 Another defect in the current wording concerns the iterators used to
10972 compare two elements for equality: The current wording contains the
10973 expression "(i - 1)", which is not covered by 25/9 [Note: See DR
10974 submitted by Thomas Mang regarding invalid iterator arithmetic
10980 25.2.8 [lib.alg.unique], paragraph 2:
10982 <p>Current wording says:
10983 "Returns: The end of the resulting range."</p>
10986 The resulting range is not specified. In combination with 25.2.8
10987 [lib.alg.unique], paragraph 1, one reasonable interpretation (in the
10988 author's opinion even the only possible interpretation) of this
10989 so-called resulting range is the range [first, last) - thus returning
10990 always the ForwardIterator 'last' parameter.
10993 <p>2) Description of intended behavior:</p>
10996 For the rest of this Defect Report, it is assumed that the intended
10997 behavior was that all elements denoted by the original range [first,
10998 last) which are the first element from a consecutive group of elements
10999 for which the corresponding conditions: *(i-1) == *i (for the version of
11000 unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
11001 the version of unique with a predicate argument) [Note: If such a group
11002 of elements consists of only a single element, this is also considered
11003 the first element] [Note: See resolutions of DR 202], call them
11004 s-elements [Note: s...stay], will be placed into a contiguous subrange
11005 of [first, last), denoted by the iterators [first, return value). The
11006 number of elements in the resulting range [first, return value) shall be
11007 equal to the number of s-elements in the original range [first, last).
11008 Invalid iterator arithmetic expressions are expected to be resolved as
11009 proposed in DR submitted by Thomas Mang regarding invalid iterator
11010 arithmetic expressions. It is also assumed by the author that the
11011 relative order of the elements in the resulting subrange [first, return
11012 value) shall be the same as the relative order of the corresponding
11013 elements (the s-elements) in the original range [Note: If this was not
11014 intended behavior, the additional proposed paragraph about stable order
11015 will certainly become obsolete].
11016 Furthermore, the resolutions of DR 202 are partially considered.
11020 All implementations known to the author of this Defect Report comply
11021 with this intent [Note: Except possible effects of DR 202]. Since this
11022 intent of the behavior (contrary to the current wording) is also
11023 described in various utility references serving the C++ community [1],
11024 it is not expected that fixing the paragraphs will influence current
11025 code [Note: Except possible effects of DR 202] - unless the code relies
11026 on the behavior as it is described by current wording and the
11027 implementation indeed reflects the current wording, and not the intent.
11032 <p>3) Proposed fixes:</p>
11035 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
11039 "Effect: Places the first element from every consecutive group of
11040 elements, referred to by the iterator i in the range [first, last), for
11041 which the following conditions hold: *(i-1) == *i (for the version of
11042 unique without a predicate argument) or pred(*(i -1), *i) != false (for
11043 the version of unique with a predicate argument), into the subrange
11044 [first, k) of the original range, where k shall denote a value of type
11048 <p>Comments to the new wording:</p>
11051 a) The new wording was influenced by the resolutions of DR 202. If DR
11052 202 is resolved in another way, the proposed wording need also
11054 b) "Places" has no special meaning, and the everyday language meaning
11056 c) The expression "(i - 1)" was left, but is expected that DR submitted
11057 by Thomas Mang regarding invalid iterator arithmetic expressions will
11058 take this into account.
11059 d) The wording "(for the version of unique without a predicate
11060 argument)" and "(for the version of unique with a predicate argument)"
11061 was added consciously for clarity and is in resemblence with current
11062 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
11063 e) The wording "of the original range" might be redundant, since any
11064 subrange starting at first and containing no more elements than the
11065 original range is implicitly a subrange of the original range [first,
11067 f) The iterator k was introduced instead of "return value" in order to
11068 avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
11069 wording ", where k shall denote a value of type ForwardIterator" might
11070 be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
11072 g) "Places" does, in the author's opinion, explicitly forbid duplicating
11073 any s-element in the original range [first, last) within the resulting
11074 range [first, k). If there is doubt this term might be not unambiguous
11075 regarding this, it is suggested that k is specified more closely by the
11076 following wording: "k shall denote a value of type ForwardIterator
11077 [Note: See f)] so that k - first is equal to the number of elements in
11078 the original range [first, last) being the first element from every
11079 consecutive group of elements for which the corresponding condition did
11080 hold". This could also be expressed as a separate paragraph
11082 h) If it is considered that the wording is unclear whether it declares
11083 the element of a group which consists of only a single element
11084 implicitly to be the first element of this group [Note: Such an
11085 interpretation could eventually arise especially in case last - first ==
11086 1] , the following additional sentence is proposed: "If such a group of
11087 elements consists of only a single element, this element is also
11088 considered the first element."
11092 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
11093 "Returns: The iterator k."
11097 Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
11098 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
11099 [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
11100 the preceding expressions are used, or the preceding expressions shall
11101 be eliminated if wording inside {} is used):
11105 "Notes:{Postcondition:} Stable: the relative order of the elements that
11106 are placed into the subrange [first, return value {k}) shall be the same
11107 as their relative order was in the original range [first, last) prior to
11108 application of the algorithm."
11111 <p>Comments to the new wording:</p>
11114 a) It is assumed by the author that the algorithm was intended to be
11116 In case this was not the intent, this paragraph becomes certainly
11118 b) The wording "was ... prior to application of the algorithm" is used
11119 to explicitly distinguish the original range not only by means of
11120 iterators, but also by a 'chronological' factor from the resulting range
11121 [first, return value). It might be redundant.
11125 25.2.8 [lib.alg.unique], paragraph 3:
11130 4) References to other DRs:
11134 See DR 202, but which does not address any of the problems described in
11135 this Defect Report [Note: This DR is supposed to complement DR 202].
11137 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
11143 The wording of these references is not always unambiguous, and provided
11144 examples partially contradict verbal description of the algorithms,
11145 because the verbal description resembles the problematic wording of
11146 ISO/IEC 14882:2003.
11151 Illustration of conforming implementations according to current wording:
11155 One way the author of this DR considers how this "elimination" could be
11156 achieved by a conforming implementation according to current wording is
11157 by substituting each r-element by _any_ s-element [Note: s...stay; any
11158 non-r-element], since all r-elements are "eliminated".
11162 In case of a sequence consisting of elements being all 'equal' [Note:
11163 See DR 202], substituting each r-element by the single s-element is the
11164 only possible solution according to current wording.
11168 <p><b>Proposed resolution:</b></p>
11171 <p><b>Rationale:</b></p>
11172 <p>The LWG believes the standard is sufficiently clear. No
11173 implementers get it wrong, and changing it wouldn't cause any code to
11174 change, so there is no real-world harm here.</p>
11181 <h3><a name="491"></a>491. std::list<>::unique incorrectly specified</h3>
11182 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11183 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2010-10-29</p>
11184 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
11185 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11186 <p><b>Discussion:</b></p>
11187 <p>In Section 23.3.4.4 [list.ops], paragraphs 19 to 21 describe the
11188 behavior of the std::list<T, Allocator>::unique operation. However, the
11189 current wording is defective for various reasons.</p>
11194 1) Analysis of current wording:
11197 <p>23.3.4.4 [list.ops], paragraph 19:</p>
11200 Current wording says:
11201 "Effects: Eliminates all but the first element from every consecutive
11202 group of equal elements referred to by the iterator i in the range
11203 [first + 1, last) for which *i == *(i - 1) (for the version of unique
11204 with no argument) or pred(*i, *(i -1)) (for the version of unique with a
11205 predicate argument) holds."</p>
11208 This sentences makes use of the undefined term "Eliminates". Although it
11209 is, to a certain degree, reasonable to consider the term "eliminate"
11210 synonymous with "erase", using "Erase" in the first place, as the
11211 wording of 23.3.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
11214 The range of the elements referred to by iterator i is "[first + 1,
11215 last)". However, neither "first" nor "last" is defined.</p>
11218 The sentence makes three times use of iterator arithmetic expressions (
11219 "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
11220 defined for bidirectional iterator [see DR submitted by Thomas Mang
11221 regarding invalid iterator arithmetic expressions].</p>
11224 The same problems as pointed out in DR 202 (equivalence relation / order
11225 of arguments for pred()) apply to this paragraph.</p>
11228 23.3.4.4 [list.ops], paragraph 20:
11232 Current wording says:
11233 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
11234 pred(*i, *(i - 1))"</p>
11237 The sentence makes two times use of invalid iterator arithmetic
11238 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
11241 [Note: Minor typos: "in" / missing dot at end of sentence.]
11245 23.3.4.4 [list.ops], paragraph 21:</p>
11248 Current wording says:
11249 "Complexity: If the range (last - first) is not empty, exactly (last -
11250 first) - 1 applications of the corresponding predicate, otherwise no
11251 application of the predicate.</p>
11254 See DR 315 regarding "(last - first)" not yielding a range.</p>
11257 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
11260 <p>2) Description of intended behavior:</p>
11263 For the rest of this Defect Report, it is assumed that "eliminate" is
11264 supposed to be synonymous to "erase", that "first" is equivalent to an
11265 iterator obtained by a call to begin(), "last" is equivalent to an
11266 iterator obtained by a call to end(), and that all invalid iterator
11267 arithmetic expressions are resolved as described in DR submitted by
11268 Thomas Mang regarding invalid iterator arithmetic expressions.</p>
11271 Furthermore, the resolutions of DR 202 are considered regarding
11272 equivalence relation and order of arguments for a call to pred.</p>
11275 All implementations known to the author of this Defect Report comply
11276 with these assumptions, apart from the impact of the alternative
11277 resolution of DR 202. Except for the changes implied by the resolutions
11278 of DR 202, no impact on current code is expected.</p>
11281 3) Proposed fixes:</p>
11284 Change 23.3.4.4 [list.ops], paragraph 19 to:</p>
11287 "Effect: Erases all but the first element from every consecutive group
11288 of elements, referred to by the iterator i in the range [begin(),
11289 end()), for which the following conditions hold: *(i-1) == *i (for the
11290 version of unique with no argument) or pred(*(i-1), *i) != false (for
11291 the version of unique with a predicate argument)."</p>
11294 Comments to the new wording:</p>
11297 a) The new wording was influenced by DR 202 and the resolutions
11298 presented there. If DR 202 is resolved in another way, the proposed
11299 wording need also additional review.
11300 b) "Erases" refers in the author's opinion unambiguously to the member
11301 function "erase". In case there is doubt this might not be unamgibuous,
11302 a direct reference to the member function "erase" is suggested [Note:
11303 This would also imply a change of 23.3.4.4 [list.ops], paragraph
11305 c) The expression "(i - 1)" was left, but is expected that DR submitted
11306 by Thomas Mang regarding invalid iterator arithmetic expressions will
11307 take this into account.
11308 d) The wording "(for the version of unique with no argument)" and "(for
11309 the version of unique with a predicate argument)" was kept consciously
11311 e) "begin()" substitutes "first", and "end()" substitutes "last". The
11312 range need adjustment from "[first + 1, last)" to "[begin(), end())" to
11313 ensure a valid range in case of an empty list.
11314 f) If it is considered that the wording is unclear whether it declares
11315 the element of a group which consists of only a single element
11316 implicitly to be the first element of this group [Note: Such an
11317 interpretation could eventually arise especially in case size() == 1] ,
11318 the following additional sentence is proposed: "If such a group of
11319 elements consists of only a single element, this element is also
11320 considered the first element."</p>
11323 Change 23.3.4.4 [list.ops], paragraph 20 to:</p>
11326 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
11327 pred(*(i-1), *i)."</p>
11330 Comments to the new wording:</p>
11333 a) The wording regarding the conditions is identical to proposed
11334 23.3.4.4 [list.ops], paragraph 19. If 23.3.4.4 [list.ops],
11335 paragraph 19 is resolved in another way, the proposed wording need also
11337 b) The expression "(i - 1)" was left, but is expected that DR submitted
11338 by Thomas Mang regarding invalid iterator arithmetic expressions will
11339 take this into account.
11340 c) Typos fixed.</p>
11343 Change 23.3.4.4 [list.ops], paragraph 21 to:</p>
11346 "Complexity: If empty() == false, exactly size() - 1 applications of the
11347 corresponding predicate, otherwise no applications of the corresponding
11351 Comments to the new wording:</p>
11354 a) The new wording is supposed to also replace the proposed resolution
11355 of DR 315, which suffers from the problem of undefined "first" / "last".
11359 5) References to other DRs:</p>
11364 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
11369 <p><b>Proposed resolution:</b></p>
11372 <p><b>Rationale:</b></p>
11373 <p>"All implementations known to the author of this Defect Report
11374 comply with these assumption", and "no impact on current code is
11375 expected", i.e. there is no evidence of real-world confusion or
11383 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
11384 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11385 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2010-10-29</p>
11386 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
11387 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11388 <p><b>Discussion:</b></p>
11389 <p>Various clauses other than clause 25 make use of iterator arithmetic not
11390 supported by the iterator category in question.
11391 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
11392 paragraph 9, but this paragraph does not provide semantics to the
11393 expression "iterator - n", where n denotes a value of a distance type
11394 between iterators.</p>
11396 <p>1) Examples of current wording:</p>
11398 <p>Current wording outside clause 25:</p>
11401 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
11403 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
11404 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
11405 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
11406 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
11407 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
11411 [Important note: The list is not complete, just an illustration. The
11412 same issue might well apply to other paragraphs not listed here.]</p>
11414 <p>None of these expressions is valid for the corresponding iterator
11417 <p>Current wording in clause 25:</p>
11420 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
11421 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
11423 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
11424 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
11428 However, current wording of 25 [lib.algorithms], paragraph 9 covers
11429 neither of these four cases:</p>
11431 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
11434 "In the description of the algorithms operator + and - are used for some
11435 of the iterator categories for which they do not have to be defined. In
11436 these cases the semantics of a+n is the same as that of</p>
11442 <p>and that of b-a is the same as of return distance(a, b)"</p>
11445 This paragrpah does not take the expression "iterator - n" into account,
11446 where n denotes a value of a distance type between two iterators [Note:
11447 According to current wording, the expression "iterator - n" would be
11448 resolved as equivalent to "return distance(n, iterator)"]. Even if the
11449 expression "iterator - n" were to be reinterpreted as equivalent to
11450 "iterator + -n" [Note: This would imply that "a" and "b" were
11451 interpreted implicitly as values of iterator types, and "n" as value of
11452 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
11453 may be negative only for random access and bidirectional iterators.",
11454 and none of the paragraphs quoted above requires the iterators on which
11455 the algorithms operate to be of random access or bidirectional category.
11458 <p>2) Description of intended behavior:</p>
11461 For the rest of this Defect Report, it is assumed that the expression
11462 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
11463 described in current 25 [lib.algorithms], paragraph 9, but applying to
11464 all clauses. The expression "iterator1 - n" is equivalent to an
11465 result-iterator for which the expression "result-iterator + n" yields an
11466 iterator denoting the same position as iterator1 does. The terms
11467 "iterator1", "iterator2" and "result-iterator" shall denote the value of
11468 an iterator type, and the term "n" shall denote a value of a distance
11469 type between two iterators.</p>
11472 All implementations known to the author of this Defect Report comply
11473 with these assumptions.
11474 No impact on current code is expected.</p>
11476 <p>3) Proposed fixes:</p>
11479 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
11482 "In the description of the algorithms operator + and - are used for some
11483 of the iterator categories for which they do not have to be defined. In
11484 this paragraph, a and b denote values of an iterator type, and n denotes
11485 a value of a distance type between two iterators. In these cases the
11486 semantics of a+n is the same as that of</p>
11492 <p>,the semantics of a-n denotes the value of an iterator i for which the
11493 following condition holds:
11494 advance(i, n) == a,
11495 and that of b-a is the same as of
11496 return distance(a, b)".
11499 <p>Comments to the new wording:</p>
11502 a) The wording " In this paragraph, a and b denote values of an iterator
11503 type, and n denotes a value of a distance type between two iterators."
11504 was added so the expressions "b-a" and "a-n" are distinguished regarding
11505 the types of the values on which they operate.
11506 b) The wording ",the semantics of a-n denotes the value of an iterator i
11507 for which the following condition holds: advance(i, n) == a" was added
11508 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
11509 was used to avoid a dependency on the semantics of a+n, as the wording
11510 "i + n == a" would have implied. However, such a dependency might well
11512 c) DR 225 is not considered in the new wording.
11516 Proposed fixes regarding invalid iterator arithmetic expressions outside
11521 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
11522 before any current invalid iterator arithmetic expression. In that case,
11523 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
11524 modified and could read: "For the rest of this International Standard,
11525 ...." / "In the description of the following clauses including this
11526 ...." / "In the description of the text below ..." etc. - anyways
11527 substituting the wording "algorithms", which is a straight reference to
11529 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
11532 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
11533 paragraph 9, to the beginning of each clause containing invalid iterator
11534 arithmetic expressions.
11536 c) Fix each paragraph (both current wording and possible resolutions of
11537 DRs) containing invalid iterator arithmetic expressions separately.
11540 <p>5) References to other DRs:</p>
11544 See DR 237. The resolution could then also read "Linear in last -
11554 Keep open and ask Bill to provide wording.
11558 2009-05-09 Alisdair adds:
11563 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>.
11573 Hinnant: this isn't going to change any user's code or any vendor's implementation.
11576 No objection to "NAD without prejudice." If anyone proposes a
11577 resolution, the LWG will consider it.
11586 <p><b>Proposed resolution:</b></p>
11588 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
11589 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
11590 not quite broad enough, because there are some arithmetic expressions
11591 it doesn't cover. Bill will provide wording.]</i></p>
11600 <h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
11601 <p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11602 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-12-13 <b>Last modified:</b> 2010-10-29</p>
11603 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
11604 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11605 <p><b>Discussion:</b></p>
11606 <p>1) In 24.1.1/3, the following text is currently present.</p>
11608 <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
11609 not guarantee the substitution property or referential transparency)."</p>
11611 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
11613 <p>"pre: r is dereferenceable.
11614 post: any copies of the previous value of r are no longer required
11615 either to be dereferenceable ..."</p>
11617 <p>While a==b does not imply that b is a copy of a, this statement should
11618 perhaps still be made more clear.</p>
11620 <p>2) There are no changes to intended behaviour</p>
11623 3) This Note should be altered to say "Note: For input iterators a==b,
11624 when its behaviour is defined ++a==++b may still be false (Equality does
11625 not guarantee the substitution property or referential transparency).</p>
11629 <p><b>Proposed resolution:</b></p>
11632 <p><b>Rationale:</b></p>
11633 <p>This is descriptive text, not normative, and the meaning is clear.</p>
11640 <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
11641 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11642 <b>Submitter:</b> Hans B os <b>Opened:</b> 2004-12-19 <b>Last modified:</b> 2010-10-29</p>
11643 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
11644 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
11645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11646 <p><b>Discussion:</b></p>
11647 <p>According to [lib.associative.reqmts] table 69, the runtime comlexity
11648 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
11650 <p>It was my understanding that an associative container could be
11651 implemented as a balanced binary tree.</p>
11653 <p>For inser(p, t), you 'll have to iterate to p's next node to see if t
11654 can be placed next to p. Furthermore, the insertion usually takes
11655 place at leaf nodes. An insert next to the root node will be done at
11656 the left of the root next node</p>
11658 <p>So when p is the root node you 'll have to iterate from the root to
11659 its next node, which takes O(log(size)) time in a balanced tree.</p>
11661 <p>If you insert all values with insert(root, t) (where root is the
11662 root of the tree before insertion) then each insert takes O(log(size))
11663 time. The amortized complexity per insertion will be O(log(size))
11666 <p>For erase(q), the normal algorithm for deleting a node that has no
11667 empty left or right subtree, is to iterate to the next (or previous),
11668 which is a leaf node. Then exchange the node with the next and delete
11669 the leaf node. Furthermore according to DR 130, erase should return
11670 the next node of the node erased. Thus erasing the root node,
11671 requires iterating to the next node.</p>
11673 <p>Now if you empty a map by deleting the root node until the map is
11674 empty, each operation will take O(log(size)), and the amortized
11675 complexity is still O(log(size)).</p>
11677 <p>The operations can be done in amortized constant time if iterating
11678 to the next node can be done in (non amortized) constant time. This
11679 can be done by putting all nodes in a double linked list. This
11680 requires two extra links per node. To me this is a bit overkill since
11681 you can already efficiently insert or erase ranges with erase(first,
11682 last) and insert(first, last).</p>
11686 <p><b>Proposed resolution:</b></p>
11689 <p><b>Rationale:</b></p>
11690 <p>Only "amortized constant" in special circumstances, and we believe
11691 that's implementable. That is: doing this N times will be O(N), not
11699 <h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
11700 <p><b>Section:</b> 25.4.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
11701 <b>Submitter:</b> Prateek Karandikar <b>Opened:</b> 2005-04-12 <b>Last modified:</b> 2010-10-29</p>
11702 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
11703 <p><b>Discussion:</b></p>
11705 17.3.1.1 Summary</p>
11708 1 The Summary provides a synopsis of the category, and introduces the
11709 first-level subclauses. Each subclause also provides a summary, listing
11710 the headers specified in the subclause and the library entities
11711 provided in each header.
11714 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
11715 other paragraphs are normative.
11718 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
11721 25.3.1.2 stable_sort
11723 <pre>template<class RandomAccessIterator>
11724 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
11726 template<class RandomAccessIterator, class Compare>
11727 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
11730 1 Effects: Sorts the elements in the range [first, last).
11733 2 Complexity: It does at most N(log N)^2 (where N == last - first)
11734 comparisons; if enough extra memory is available, it is N log N.
11737 3 Notes: Stable: the relative order of the equivalent elements is
11742 The Notes para is informative, and nowhere else is stability mentioned above.
11746 Also, I just searched for the word "stable" in my copy of the Standard.
11747 and the phrase "Notes: Stable: the relative order of the elements..."
11748 is repeated several times in the Standard library clauses for
11749 describing various functions. How is it that stability is talked about
11750 in the informative paragraph? Or am I missing something obvious?
11754 <p><b>Proposed resolution:</b></p>
11759 <p><b>Rationale:</b></p>
11761 This change has already been made.
11769 <h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
11770 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11771 <b>Submitter:</b> Krzysztof Żelechowski <b>Opened:</b> 2005-05-24 <b>Last modified:</b> 2010-10-29</p>
11772 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
11773 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11774 <p><b>Discussion:</b></p>
11776 <li>codecvt::do_length is of type int;</li>
11777 <li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
11778 <li>ptrdiff_t cannot be cast to an int without data loss.</li>
11785 <p><b>Proposed resolution:</b></p>
11794 <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
11795 <p><b>Section:</b> X [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11796 <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2010-10-29</p>
11797 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
11798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11799 <p><b>Discussion:</b></p>
11801 "For templates greater, less, greater_equal, and less_equal,
11802 the specializations for any pointer type yield a total order, even if
11803 the built-in operators <, >, <=, >= do not."
11807 The standard should do much better than guarantee that these provide a
11808 total order, it should guarantee that it can be used to test if memory
11809 overlaps, i.e. write a portable memmove. You can imagine a platform
11810 where the built-in operators use a uint32_t comparison (this tests for
11811 overlap on this platform) but the less<T*> functor is allowed to be
11812 defined to use a int32_t comparison. On this platform, if you use
11813 std::less with the intent of making a portable memmove, comparison on
11814 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
11819 <p><b>Proposed resolution:</b></p>
11821 Add a footnote to 20.5.3/8 saying:
11825 Given a p1 and p2 such that p1 points to N objects of type T and p2
11826 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
11827 less returns the same value when comparing all pointers in [p1,p1+N) to
11828 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
11829 such that less returns the same value when comparing all pointers in
11830 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
11831 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
11832 For the sake of completeness, the null pointer value (4.10) for T is
11833 considered to be an array of 1 object that doesn't overlap with any
11834 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
11835 and not_equal_to give the expected results based on the total ordering
11836 semantics of less. For T of void, treat it as having similar semantics
11837 as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv
11838 void*>(a, b) which gives the same results as less<cv char*>((cv
11839 char*)(cv void*)a, (cv char*)(cv void*)b).
11843 I'm also thinking there should be a footnote to 20.5.3/1 saying that if
11844 A and B are similar types (4.4/4), comp<A>(a,b) returns the same value
11845 as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might
11846 be problematic if there is some really funky operator overloading going
11847 on that does different things based on cv (that should be undefined
11848 behavior if somebody does that though). This at least should be
11849 guaranteed for all POD types (especially pointers) that use the
11850 built-in comparison operators.
11855 <p><b>Rationale:</b></p>
11857 less is already required to provide a strict weak ordering which is good enough
11858 to detect overlapping memory situations.
11866 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
11867 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11868 <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2010-10-29</p>
11869 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
11870 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11871 <p><b>Discussion:</b></p>
11877 This requirement seems obvious to me, it is the essence of code modularity.
11878 I have complained to Mr. Plauger that the Dinkumware library does not
11879 observe this principle but he objected that this behaviour is not covered in
11890 No objection to NAD, Fixed.
11899 <p><b>Proposed resolution:</b></p>
11901 Append the following point to 22.1.1.1.1:
11905 6. The implementation of a facet of Table 52 parametrized with an
11906 InputIterator/OutputIterator should use that iterator only as character
11907 source/sink respectively.
11908 For a *_get facet, it means that the value received depends only on the
11909 sequence of input characters and not on how they are accessed.
11910 For a *_put facet, it means that the sequence of characters output depends
11911 only on the value to be formatted and not of how the characters are stored.
11915 Berlin: Moved to Open, Need to clean up this area to make it clear
11916 locales don't have to contain open ended sets of facets. Jack, Howard,
11927 <h3><a name="503"></a>503. more on locales</h3>
11928 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11929 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2005-06-20 <b>Last modified:</b> 2010-10-29</p>
11930 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
11931 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11932 <p><b>Discussion:</b></p>
11934 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
11935 51" to refer to the facet *objects* associated with a locale. And we
11936 almost certainly mean just those associated with the default or "C"
11937 locale. Otherwise, you can't switch to a locale that enforces a different
11938 mapping between narrow and wide characters, or that defines additional
11939 uppercase characters.
11943 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
11947 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
11948 a homing sequence for the basic character set, which might very well need
11953 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
11954 between wide and narrow characters be taken as one-for-one.
11958 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
11959 I can tell. The muddle is, as before, calling Table 51 a list of
11960 instantiations. But the constraint it applies seems to me to cover
11961 *all* defined uses of num_get/put, so why bother to say so?
11965 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
11966 return '.' or L'.'.) Presumably this means "as appropriate for the
11967 character type. But given the vague definition of "required" earlier,
11968 this overrules *any* change of decimal point for non "C" locales.
11969 Surely we don't want to do that.
11973 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
11974 return ',' or L','.) As above, this probably means "as appropriate for the
11975 character type. But this overrules the "C" locale, which requires *no*
11976 character ('\0') for the thousands separator. Even if we agree that we
11977 don't mean to block changes in decimal point or thousands separator,
11978 we should also eliminate this clear incompatibility with C.
11982 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
11983 return the empty string, indicating no grouping." Same considerations
11984 as for do_decimal_point.
11988 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
11989 51". Same bad jargon.
11993 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
11994 in Table 51". Same bad jargon.
11998 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
12003 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
12008 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
12009 in Table 51 ... return an object of type pattern initialized to
12010 {symbol, sign, none, value}." This once again *overrides* the "C"
12011 locale, as well as any other locale."
12015 3) We constrain the use_facet calls that can be made by num_get/put,
12016 so why don't we do the same for money_get/put? Or for any of the
12017 other facets, for that matter?
12021 4) As an almost aside, we spell out when a facet needs to use the ctype
12022 facet, but several also need to use a codecvt facet and we don't say so.
12025 Berlin: Bill to provide wording.
12036 No objection to NAD.
12045 <p><b>Proposed resolution:</b></p>
12054 <h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
12055 <p><b>Section:</b> 26.5.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
12056 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12057 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
12058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
12059 <p><b>Discussion:</b></p>
12061 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
12062 g is an ... object returning values of unsigned integral type ..."
12066 <p><b>Proposed resolution:</b></p>
12068 In 5.1.1 [tr.rand.req], Paragraph 2 replace
12072 ... s is a value of integral type, g is an lvalue of a type other than X that
12073 defines a zero-argument function object returning values of <del>unsigned integral</del> type
12074 <ins><tt>unsigned long int</tt></ins>,
12079 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
12083 creates an engine with the initial internal state
12084 determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
12088 Mont Tremblant: Both s and g should be unsigned long.
12089 This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
12094 Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved
12101 <p><b>Rationale:</b></p>
12103 Jens: Just requiring X(unsigned long) still makes it possible
12104 for an evil library writer to also supply a X(int) that does something
12105 unexpected. The wording above requires that X(s) always performs
12106 as if X(unsigned long) would have been called. I believe that is
12107 sufficient and implements our intentions from Mont Tremblant. I
12108 see no additional use in actually requiring a X(unsigned long)
12109 signature. u.seed(s) is covered by its reference to X(s), same
12115 Portland: Subsumed by N2111.
12123 <h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
12124 <p><b>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12125 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12126 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
12127 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12128 <p><b>Discussion:</b></p>
12130 Paragraph 3 requires that template argument U (which corresponds to template
12131 parameter Engine) satisfy all uniform random number generator requirements.
12132 However, there is no analogous requirement regarding the template argument
12133 that corresponds to template parameter Distribution. We believe there should
12134 be, and that it should require that this template argument satisfy all random
12135 distribution requirements.
12139 <p><b>Proposed resolution:</b></p>
12141 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
12144 Consequence 2: Add max() and min() functions to those distributions that
12145 do not already have them.
12149 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
12150 Marc supports having min and max to satisfy generic programming interface.
12156 <p><b>Rationale:</b></p>
12157 <p>Berlin: N1932 makes this moot: variate_generator has been eliminated.</p>
12164 <h3><a name="509"></a>509. Uniform_int template parameters</h3>
12165 <p><b>Section:</b> 26.5.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12166 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12167 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
12168 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12169 <p><b>Discussion:</b></p>
12171 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
12172 template parameter, IntType, used as the input_type and as the result_type
12173 of the distribution. We believe there is no reason to conflate these types
12178 <p><b>Proposed resolution:</b></p>
12180 We recommend that there be a second template parameter to
12181 reflect the distribution's input_type, and that the existing first template
12182 parameter continue to reflect (solely) the result_type:
12184 <blockquote><pre>template< class IntType = int, UIntType = unsigned int >
12189 typedef UIntType input_type;
12190 typedef IntType result_type;
12191 </pre></blockquote>
12194 Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
12205 <h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
12206 <p><b>Section:</b> 26.5.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12207 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12209 <p><b>Discussion:</b></p>
12211 In [tr.rand.dist.bern] the distribution currently requires;
12213 <blockquote><pre>typedef int input_type;
12214 </pre></blockquote>
12217 <p><b>Proposed resolution:</b></p>
12219 We believe this is an unfortunate choice, and recommend instead:
12221 <blockquote><pre>typedef unsigned int input_type;
12222 </pre></blockquote>
12225 Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
12236 <h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
12237 <p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12238 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12239 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
12240 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12241 <p><b>Discussion:</b></p>
12243 Unlike all other distributions in TR1, this binomial_distribution has an
12244 implementation-defined input_type. We believe this is an unfortunate choice,
12245 because it hinders users from writing portable code. It also hinders the
12246 writing of compliance tests. We recommend instead:
12248 <blockquote><pre>typedef RealType input_type;
12249 </pre></blockquote>
12251 While this choice is somewhat arbitrary (as it was for some of the other
12252 distributions), we make this particular choice because (unlike all other
12253 distributions) otherwise this template would not publish its RealType
12254 argument and so users could not write generic code that accessed this
12255 second template parameter. In this respect, the choice is consistent with
12256 the other distributions in TR1.
12259 We have two reasons for recommending that a real type be specified instead.
12260 One reason is based specifically on characteristics of binomial distribution
12261 implementations, while the other is based on mathematical characteristics of
12262 probability distribution functions in general.
12265 Implementations of binomial distributions commonly use Stirling approximations
12266 for values in certain ranges. It is far more natural to use real values to
12267 represent these approximations than it would be to use integral values to do
12268 so. In other ranges, implementations reply on the Bernoulli distribution to
12269 obtain values. While TR1's bernoulli_distribution::input_type is specified as
12270 int, we believe this would be better specified as double.
12273 This brings us to our main point: The notion of a random distribution rests
12274 on the notion of a cumulative distribution function, which in turn mathematically
12275 depends on a continuous dependent variable. Indeed, such a distribution function
12276 would be meaningless if it depended on discrete values such as integers - and this
12277 remains true even if the distribution function were to take discrete steps.
12280 Although this note is specifically about binomial_distribution::input_type,
12281 we intend to recommend that all of the random distributions input_types be
12282 specified as a real type (either a RealType template parameter, or double,
12286 Of the nine distributions in TR1, four already have this characteristic
12287 (uniform_real, exponential_distribution, normal_distribution, and
12288 gamma_distribution). We have already argued the case for the binomial the
12289 remaining four distributions.
12292 In the case of uniform_int, we believe that the calculations to produce an
12293 integer result in a specified range from an integer in a different specified
12294 range is best done using real arithmetic. This is because it involves a
12295 product, one of whose terms is the ratio of the extents of the two ranges.
12296 Without real arithmetic, the results become less uniform: some numbers become
12297 more (or less) probable that they should be. This is, of course, undesireable
12298 behavior in a uniform distribution.
12301 Finally, we believe that in the case of the bernoulli_distribution (briefly
12302 mentioned earlier), as well as the cases of the geometric_distribution and the
12303 poisson_distribution, it would be far more natural to have a real input_type.
12304 This is because the most natural computation involves the random number
12305 delivered and the distribution's parameter p (in the case of bernoulli_distribution,
12306 for example, the computation is a comparison against p), and p is already specified
12307 in each case as having some real type.
12311 <p><b>Proposed resolution:</b></p>
12312 <blockquote><pre>typedef RealType input_type;
12313 </pre></blockquote>
12316 Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
12326 <h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
12327 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
12328 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12329 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
12330 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
12331 <p><b>Discussion:</b></p>
12333 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine
12334 is to be seeded given a single unsigned long. This algorithm is seriously
12335 flawed in the case where the engine parameter w (also known as word_size)
12336 exceeds 31 [bits]. The key part of the paragraph reads:
12339 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
12345 Since the specified linear congruential engine, lcg, delivers numbers with
12346 a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
12347 example, 48, each of the x(i) will be less than 2**-17. The consequence
12348 is that roughly the first 400 numbers delivered will be conspicuously
12349 close to either zero or one.
12352 Unfortunately, this is not an innocuous flaw: One of the predefined engines
12353 in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
12354 this poor behavior, while the original N1378 proposal states that these
12355 pre-defined engines are intended to be of "known good properties."
12359 <p><b>Proposed resolution:</b></p>
12361 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
12362 void seed(unsigned long value = 19780503) by
12366 <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
12367 case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
12368 <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
12369 <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
12370 sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r)
\85 x(-1)</tt>
12371 <ins>as if executing</ins></p>
12373 <blockquote><pre><ins>
12374 linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
12376 </ins></pre></blockquote>
12379 <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
12380 \85 (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
12381 respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
12382 else sets carry<tt>(-1) = 0</tt>.</del></p>
12386 Jens provided revised wording post Mont Tremblant.
12391 Berlin: N1932 adopts the originally-proposed resolution of the issue.
12392 Jens's supplied wording is a clearer description of what is
12393 intended. Moved to Ready.
12399 <p><b>Rationale:</b></p>
12401 Jens: I'm using an explicit type here, because fixing the
12402 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
12403 stricter) requirements we have for seed(Gen&).
12407 Portland: Subsumed by N2111.
12416 <h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
12417 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
12418 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12419 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
12420 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
12421 <p><b>Discussion:</b></p>
12423 Paragraph 3 begins:
12426 The size of the state is r.
12429 However, this is not quite consistent with the remainder of the paragraph
12430 which specifies a total of nr+1 items in the textual representation of
12431 the state. We recommend the sentence be corrected to match:
12434 The size of the state is nr+1.
12437 To give meaning to the coefficient n, it may be also desirable to move
12438 n's definition from later in the paragraph. Either of the following
12439 seem reasonable formulations:
12442 With n=..., the size of the state is nr+1.
12445 The size of the state is nr+1, where n=... .
12450 <p><b>Proposed resolution:</b></p>
12452 Jens: I plead for "NAD" on the grounds that "size of state" is only
12453 used as an argument for big-O complexity notation, thus
12454 constant factors and additions don't count.
12459 Berlin: N1932 adopts the proposed NAD.
12469 <h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
12470 <p><b>Section:</b> 26.5.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
12471 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12472 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
12473 <p><b>Discussion:</b></p>
12475 Paragraph 2 begins:
12478 The size of the state is r.
12481 However, the next sentence specifies a total of r+1 items in the textual
12482 representation of the state, r specific x's as well as a specific carry.
12483 This makes a total of r+1 items that constitute the size of the state,
12488 <p><b>Proposed resolution:</b></p>
12490 We recommend the sentence be corrected to match:
12493 The size of the state is r+1.
12497 Jens: I plead for "NAD" on the grounds that "size of state" is only
12498 used as an argument for big-O complexity notation, thus
12499 constant factors and additions don't count.
12504 Berlin: N1932 adopts the proposed NAD.
12514 <h3><a name="515"></a>515. Random number engine traits</h3>
12515 <p><b>Section:</b> 26.5.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12516 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12517 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
12518 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12519 <p><b>Discussion:</b></p>
12521 To accompany the concept of a pseudo-random number engine as defined in Table 17,
12522 we propose and recommend an adjunct template, engine_traits, to be declared in
12523 [tr.rand.synopsis] as:
12525 <blockquote><pre>template< class PSRE >
12526 class engine_traits;
12527 </pre></blockquote>
12529 This template's primary purpose would be as an aid to generic programming involving
12530 pseudo-random number engines. Given only the facilities described in tr1, it would
12531 be very difficult to produce any algorithms involving the notion of a generic engine.
12532 The intent of this proposal is to provide, via engine_traits<>, sufficient
12533 descriptive information to allow an algorithm to employ a pseudo-random number engine
12534 without regard to its exact type, i.e., as a template parameter.
12537 For example, today it is not possible to write an efficient generic function that
12538 requires any specific number of random bits. More specifically, consider a
12539 cryptographic application that internally needs 256 bits of randomness per call:
12541 <blockquote><pre>template< class Eng, class InIter, class OutIter >
12542 void crypto( Eng& e, InIter in, OutIter out );
12543 </pre></blockquote>
12545 Without knowning the number of bits of randomness produced per call to a provided
12546 engine, the algorithm has no means of determining how many times to call the engine.
12549 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
12552 <blockquote><pre>template< class PSRE >
12553 class engine_traits
12555 static std::size_t bits_of_randomness = 0u;
12556 static std::string name() { return "unknown_engine"; }
12557 // TODO: other traits here
12559 </pre></blockquote>
12561 Further, each engine described in [tr.rand.engine] would be accompanied by a
12562 complete specialization of this new engine_traits template.
12567 <p><b>Proposed resolution:</b></p>
12569 Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this
12570 feature. Recommend close as NAD.
12575 <p><b>Rationale:</b></p>
12578 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
12579 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
12580 covers this. Already in WP.
12588 <h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
12589 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
12590 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12591 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
12592 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
12593 <p><b>Discussion:</b></p>
12598 ... obtained by successive invocations of g, ...
12601 We recommend instead:
12604 ... obtained by taking successive invocations of g mod 2**32, ...
12607 as the context seems to require only 32-bit quantities be used here.
12611 <p><b>Proposed resolution:</b></p>
12613 Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready.
12617 Portland: Subsumed by N2111.
12626 <h3><a name="517"></a>517. Should include name in external representation</h3>
12627 <p><b>Section:</b> 26.5.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12628 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
12629 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
12630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12631 <p><b>Discussion:</b></p>
12633 The last two rows of Table 16 deal with the i/o requirements of an engine,
12634 specifying that the textual representation of an engine's state,
12635 appropriately formatted, constitute the engine's external representation.
12638 This seems adequate when an engine's type is known. However, it seems
12639 inadequate in the context of generic code, where it becomes useful and
12640 perhaps even necessary to determine an engine's type via input.
12646 <p><b>Proposed resolution:</b></p>
12648 We therefore recommend that, in each of these two rows of Table 16, the
12649 text "textual representation" be expanded so as to read "engine name
12650 followed by the textual representation."
12654 Berlin: N1932 considers this NAD. This is a QOI issue.
12664 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
12665 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
12666 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2010-10-29</p>
12667 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
12668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
12669 <p><b>Discussion:</b></p>
12671 A problem with TR1 regex is currently being discussed on the Boost
12672 developers list. It involves the handling of case-insensitive matching
12673 of character ranges such as [Z-a]. The proper behavior (according to the
12674 ECMAScript standard) is unimplementable given the current specification
12675 of the TR1 regex_traits<> class template. John Maddock, the author of
12676 the TR1 regex proposal, agrees there is a problem. The full discussion
12677 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
12678 message copied below). We don't have any recommendations as yet.
12681 -- Begin original message --
12684 The situation of interest is described in the ECMAScript specification
12685 (ECMA-262), section 15.10.2.15:
12688 "Even if the pattern ignores case, the case of the two ends of a range
12689 is significant in determining which characters belong to the range.
12690 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
12691 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
12692 ASCII letters as well as the symbols [, \, ], ^, _, and `."
12695 A more interesting case is what should happen when doing a
12696 case-insentitive match on a range such as [Z-a]. It should match z, Z,
12697 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
12698 Boost.Regex (it throws an exception from the regex constructor).
12701 The tough pill to swallow is that, given the specification in TR1, I
12702 don't think there is any effective way to handle this situation.
12703 According to the spec, case-insensitivity is handled with
12704 regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
12705 if they compare equal after both are sent through the translate_nocase
12706 function. But I don't see any way of using this translation function to
12707 make character ranges case-insensitive. Consider the difficulty of
12708 detecting whether "z" is in the range [Z-a]. Applying the transformation
12709 to "z" has no effect (it is essentially std::tolower). And we're not
12710 allowed to apply the transformation to the ends of the range, because as
12711 ECMA-262 says, "the case of the two ends of a range is significant."
12714 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
12715 is to redefine translate_nocase to return a string_type containing all
12716 the characters that should compare equal to the specified character. But
12717 this function is hard to implement for Unicode, and it doesn't play nice
12718 with the existing ctype facet. What a mess!
12721 -- End original message --
12730 One small correction, I have since found that ICU's regex package does
12731 implement this correctly, using a similar mechanism to the current
12735 Given an expression [c1-c2] that is compiled as case insensitive it:
12738 Enumerates every character in the range c1 to c2 and converts it to it's
12739 case folded equivalent. That case folded character is then used a key to a
12740 table of equivalence classes, and each member of the class is added to the
12741 list of possible matches supported by the character-class. This second step
12742 isn't possible with our current traits class design, but isn't necessary if
12743 the input text is also converted to a case-folded equivalent on the fly.
12746 ICU applies similar brute force mechanisms to character classes such as
12747 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
12748 is less noticeable in this case.
12751 Quick and dirty performance comparisons show that expressions such as
12752 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
12753 slower than a "normal" expression). For an application that uses a lot of
12754 regexes this could have a noticeable performance impact. ICU also has an
12755 advantage in that it knows the range of valid characters codes: code points
12756 outside that range are assumed not to require enumeration, as they can not
12757 be part of any equivalence class. I presume that if we want the TR1.Regex
12758 to work with arbitrarily large character sets enumeration really does become
12762 Finally note that Unicode has:
12765 Three cases (upper, lower and title).
12766 One to many, and many to one case transformations.
12767 Character that have context sensitive case translations - for example an
12768 uppercase sigma has two different lowercase forms - the form chosen depends
12769 on context(is it end of a word or not), a caseless match for an upper case
12770 sigma should match either of the lower case forms, which is why case folding
12771 is often approximated by tolower(toupper(c)).
12774 Probably we need some way to enumerate character equivalence classes,
12775 including digraphs (either as a result or an input), and some way to tell
12776 whether the next character pair is a valid digraph in the current locale.
12779 Hoping this doesn't make this even more complex that it was already,
12783 Portland: Alisdair: Detect as invalid, throw an exception.
12784 Pete: Possible general problem with case insensitive ranges.
12795 We agree that this is a problem, but we do not know the answer.
12798 We are going to declare this NAD until existing practice leads us in some direction.
12801 No objection to NAD Future.
12804 Move to NAD Future.
12810 <p><b>Proposed resolution:</b></p>
12817 <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
12818 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12819 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2005-09-14 <b>Last modified:</b> 2010-10-29</p>
12820 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
12821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12822 <p><b>Discussion:</b></p>
12824 Problem: There are a number of places in the C++ standard library where
12825 it is possible to write what appear to be sensible ways of calling
12826 functions, but which can cause problems in some (or all)
12827 implementations, as they cause the values given to the function to be
12828 changed in a way not specified in standard (and therefore not coded to
12829 correctly work). These fall into two similar categories.
12833 1) Parameters taken by const reference can be changed during execution
12842 Given std::vector<int> v:
12845 v.insert(v.begin(), v[2]);
12848 v[2] can be changed by moving elements of vector
12853 Given std::list<int> l:
12856 l.remove(*l.begin());
12859 Will delete the first element, and then continue trying to access it.
12860 This is particularily vicious, as it will appear to work in almost all
12865 2) A range is given which changes during the execution of the function:
12870 v.insert(v.begin(), v.begin()+4, v.begin()+6);
12874 This kind of problem has been partly covered in some cases. For example
12875 std::copy(first, last, result) states that result cannot be in the range
12876 [first, last). However, does this cover the case where result is a
12877 reverse_iterator built from some iterator in the range [first, last)?
12878 Also, std::copy would still break if result was reverse_iterator(last +
12879 1), yet this is not forbidden by the standard
12887 One option would be to try to more carefully limit the requirements of
12888 each function. There are many functions which would have to be checked.
12889 However as has been shown in the std::copy case, this may be difficult.
12890 A simpler, more global option would be to somewhere insert text similar to:
12894 If the execution of any function would change either any values passed
12895 by reference or any value in any range passed to a function in a way not
12896 defined in the definition of that function, the result is undefined.
12900 Such code would have to at least cover chapters 23 and 25 (the sections
12901 I read through carefully). I can see no harm on applying it to much of
12902 the rest of the standard.
12906 Some existing parts of the standard could be improved to fit with this,
12907 for example the requires for 25.2.1 (Copy) could be adjusted to:
12911 Requires: For each non-negative integer n < (last - first), assigning to
12912 *(result + n) must not alter any value in the range [first + n, last).
12916 However, this may add excessive complication.
12920 One other benefit of clearly introducing this text is that it would
12921 allow a number of small optimisations, such as caching values passed
12922 by const reference.
12926 Matt Austern adds that this issue also exists for the <tt>insert</tt> and
12927 <tt>erase</tt> members of the ordered and unordered associative containers.
12931 Berlin: Lots of controversey over how this should be solved. Lots of confusion
12932 as to whether we're talking about self referencing iterators or references.
12933 Needs a good survey as to the cases where this matters, for which
12934 implementations, and how expensive it is to fix each case.
12940 <p><b>Proposed resolution:</b></p>
12943 <p><b>Rationale:</b></p>
12948 <li><tt>vector::insert(iter, value)</tt> is required to work because the standard
12949 doesn't give permission for it not to work.</li>
12950 <li><tt>list::remove(value)</tt> is required to work because the standard
12951 doesn't give permission for it not to work.</li>
12952 <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
12953 23.2.3 [sequence.reqmts], p4 says so.</li>
12954 <li><tt>copy</tt> has to work, except where 25.3.1 [alg.copy] says
12955 it doesn't have to work. While a language lawyer can tear this wording apart,
12956 it is felt that the wording is not prone to accidental interpretation.</li>
12957 <li>The current working draft provide exceptions for the unordered associative
12958 containers similar to the containers requirements which exempt the member
12959 template insert functions from self referencing.</li>
12967 <h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
12968 <p><b>Section:</b> 23.7 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12969 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-10-12 <b>Last modified:</b> 2010-10-29</p>
12970 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
12971 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12972 <p><b>Discussion:</b></p>
12974 while implementing the resolution of issue 6.19 I'm noticing the
12975 following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
12976 unordered_multiset:
12980 "The iterator and const_iterator types are both const types. It is
12981 unspecified whether they are the same type"
12985 Now, according to the resolution of 6.19, we have overloads of insert
12986 with hint and erase (single and range) both for iterator and
12987 const_iterator, which, AFAICS, can be meaningful at the same time *only*
12988 if iterator and const_iterator *are* in fact different types.
12991 Then, iterator and const_iterator are *required* to be different types?
12992 Or that is an unintended consequence? Maybe the overloads for plain
12993 iterators should be added only to unordered_map and unordered_multimap?
12994 Or, of course, I'm missing something?
12999 <p><b>Proposed resolution:</b></p>
13001 Add to 6.3.4.3p2 (and 6.3.4.5p2):
13004 2 ... The iterator and const_iterator types are both <del>const</del>
13005 <ins>constant</ins> iterator types.
13006 It is unspecified whether they are the same type.
13010 Add a new subsection to 17.4.4 [lib.conforming]:
13015 An implementation shall not supply an overloaded function
13016 signature specified in any library clause if such a signature
13017 would be inherently ambiguous during overload resolution
13018 due to two library types referring to the same type.
13021 [Note: For example, this occurs when a container's iterator
13022 and const_iterator types are the same. -- end note]
13027 Post-Berlin: Beman supplied wording.
13033 <p><b>Rationale:</b></p>
13034 Toronto: The first issue has been fixed by N2350 (the insert and erase members
13035 are collapsed into one signature). Alisdair to open a separate issue on the
13036 chapter 17 wording.
13043 <h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
13044 <p><b>Section:</b> 17.6.3.11 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13045 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-10-25 <b>Last modified:</b> 2010-10-29</p>
13046 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13047 <p><b>Discussion:</b></p>
13053 Violation of the preconditions specified in a function's
13054 Required behavior: paragraph results in undefined behavior unless the
13055 function's Throws: paragraph specifies throwing an exception when the
13056 precondition is violated.
13060 This implies that a precondition violation can lead to defined
13061 behavior. That conflicts with the only reasonable definition of
13062 precondition: that a violation leads to undefined behavior. Any other
13063 definition muddies the waters when it comes to analyzing program
13064 correctness, because precondition violations may be routinely done in
13065 correct code (e.g. you can use std::vector::at with the full
13066 expectation that you'll get an exception when your index is out of
13067 range, catch the exception, and continue). Not only is it a bad
13068 example to set, but it encourages needless complication and redundancy
13069 in the standard. For example:
13072 <blockquote><pre> 21 Strings library
13073 21.3.3 basic_string capacity
13075 void resize(size_type n, charT c);
13077 5 Requires: n <= max_size()
13078 6 Throws: length_error if n > max_size().
13079 7 Effects: Alters the length of the string designated by *this as follows:
13080 </pre></blockquote>
13083 The Requires clause is entirely redundant and can be dropped. We
13084 could make that simplifying change (and many others like it) even
13085 without changing 17.4.3.8/1; the wording there just seems to encourage
13086 the redundant and error-prone Requires: clause.
13090 Batavia: Alan and Pete to work.
13095 Bellevue: NAD Editorial, this group likes
13096 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>,
13097 Pete agrees, accepting it is Pete's business.
13098 General agreement that precondition violations are synonymous with UB.
13103 <p><b>Proposed resolution:</b></p>
13105 1. Change 17.4.3.8/1 to read:
13109 Violation of the preconditions specified in a function's
13110 <i>Required behavior:</i> paragraph results in undefined behavior
13111 <del>unless the function's <i>Throws:</i> paragraph specifies throwing
13112 an exception when the precondition is violated</del>.
13116 2. Go through and remove redundant Requires: clauses. Specifics to be
13117 provided by Dave A.
13121 Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
13126 Alan provided the survey
13127 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
13137 <h3><a name="532"></a>532. Tuple comparison</h3>
13138 <p><b>Section:</b> 20.4.2.7 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
13139 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29 <b>Last modified:</b> 2010-10-29</p>
13140 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
13141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
13142 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
13143 <p><b>Discussion:</b></p>
13145 Where possible, tuple comparison operators <,<=,=>, and > ought to be
13146 defined in terms of std::less rather than operator<, in order to
13147 support comparison of tuples of pointers.
13151 2009-07-28 Reopened by Alisdair. No longer solved by concepts.
13156 2009-10 Santa Cruz:
13162 If we solve this for <tt>tuple</tt> we would have to solve it for <tt>pair</tt>
13163 algorithms, etc. It is too late to do that at this time. Move to NAD Future.
13169 <p><b>Proposed resolution:</b></p>
13171 change 6.1.3.5/5 from:
13175 Returns: The result of a lexicographical comparison between t and
13176 u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) ||
13177 (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for
13178 some tuple r is a tuple containing all but the first element of
13179 r. For any two zero-length tuples e and f, e < f returns false.
13188 Returns: The result of a lexicographical comparison between t and
13189 u. For any two zero-length tuples e and f, e < f returns false.
13190 Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) ||
13191 (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some
13192 tuple r is a tuple containing all but the first element of r, and
13193 cmp(x,y) is an unspecified function template defined as follows.
13196 Where T is the type of x and U is the type of y:
13200 if T and U are pointer types and T is convertible to U, returns
13201 less<U>()(x,y)
13205 otherwise, if T and U are pointer types, returns less<T>()(x,y)
13209 otherwise, returns (bool)(x < y)
13214 Berlin: This issue is much bigger than just tuple (pair, containers,
13215 algorithms). Dietmar will survey and work up proposed wording.
13221 <p><b>Rationale:</b></p>
13223 Recommend NAD. This will be fixed with the next revision of concepts.
13233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
13241 <h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
13242 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
13243 <b>Submitter:</b> JoaquÃn M López Muñoz <b>Opened:</b> 2005-12-17 <b>Last modified:</b> 2010-10-29</p>
13244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
13245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
13246 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
13247 <p><b>Discussion:</b></p>
13249 The iterator constructor X(i,j) for containers as defined in 23.1.1 and
13250 23.2.2 does only require that i and j be input iterators but
13251 nothing is said about their associated value_type. There are three
13256 <li>iterator's value_type is exactly X::value_type (modulo cv).</li>
13257 <li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
13258 <li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
13261 The issue has practical implications, and stdlib vendors have
13262 taken divergent approaches to it: Dinkumware follows 2,
13263 libstdc++ follows 3.
13266 The same problem applies to the definition of insert(p,i,j) for
13267 sequences and insert(i,j) for associative contianers, as well as
13272 The following added by Howard and the example code was originally written by
13280 <blockquote><pre>#include <vector>
13281 #include <iterator>
13282 #include <iostream>
13286 explicit foo(int) {}
13291 std::vector<int> v_int;
13292 std::vector<foo> v_foo1(v_int.begin(), v_int.end());
13293 std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)),
13294 std::istream_iterator<int>());
13296 </pre></blockquote>
13298 Berlin: Some support, not universal, for respecting the explicit qualifier.
13304 <p><b>Proposed resolution:</b></p>
13312 <h3><a name="544"></a>544. minor NULL problems in C.2</h3>
13313 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13314 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-25 <b>Last modified:</b> 2010-10-29</p>
13315 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
13316 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13317 <p><b>Discussion:</b></p>
13319 According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>,
13320 <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>,
13321 or <cwchar>." This is consistent with the C standard.
13324 However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>.
13327 In addition, C.2, p2 claims that "The C++ Standard library provides
13328 54 standard macros from the C library, as shown in Table 95." While
13329 table 95 does have 54 entries, since a couple of them (including the
13330 NULL macro) are listed more than once, the actual number of macros
13331 defined by the C++ Standard Library may not be 54.
13335 <p><b>Proposed resolution:</b></p>
13337 I propose we add <clocale> and <cstdlib> to Table 96 and remove the
13338 number of macros from C.2, p2 and reword the sentence as follows:
13341 The C++ Standard library <del>provides 54 standard macros from</del>
13342 <ins>defines a number macros corresponding to those defined by</ins> the C
13343 <ins>Standard</ins> library, as shown in Table 96.
13347 Portland: Resolution is considered editorial. It will be incorporated into the WD.
13357 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
13358 <p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13359 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
13360 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13361 <p><b>Discussion:</b></p>
13363 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
13364 The rest of the TR should use that type. I believe this affects two places.
13365 First, the random number requirements, 5.1.1/10-11, lists all of the types with
13366 which template parameters named IntType and UIntType may be instantiated.
13367 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
13368 IntType list, and UIntType (again, or "unsigned long long") should be added to
13369 the UIntType list. Second, 6.3.2 lists the types for which hash<> is
13370 required to be instantiable. _Longlong and _Ulonglong should be added to that
13371 list, so that people may use long long as a hash key.
13381 We are not going to fix TR1.
13384 The paper "long long goes to the library" addresses the integration of
13385 long long into the C++0x library.
13394 <p><b>Proposed resolution:</b></p>
13403 <h3><a name="547"></a>547. division should be floating-point, not integer</h3>
13404 <p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13405 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
13406 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
13407 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13408 <p><b>Discussion:</b></p>
13410 Paragraph 10 describes how a variate generator uses numbers produced by an
13411 engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
13412 the value for engine_value_type::result_type is true and the value for
13413 Distribution::input_type is false [i.e. if the engine produces integers and the
13414 engine wants floating-point values], then the numbers in s_eng are divided by
13415 engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
13416 engine is producing integers, both the numerator and the denominator are
13417 integers and we'll be doing integer division, which I don't think is what we
13418 want. Shouldn't we be performing a conversion to a floating-point type first?
13422 <p><b>Proposed resolution:</b></p>
13425 <p><b>Rationale:</b></p>
13427 Recommend NAD as the affected section is now gone and so the issue is moot.
13428 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
13436 <h3><a name="548"></a>548. May random_device block?</h3>
13437 <p><b>Section:</b> 26.5.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13438 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
13439 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
13440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13441 <p><b>Discussion:</b></p>
13443 Class random_device "produces non-deterministic random numbers", using some
13444 external source of entropy. In most real-world systems, the amount of available
13445 entropy is limited. Suppose that entropy has been exhausted. What is an
13446 implementation permitted to do? In particular, is it permitted to block
13447 indefinitely until more random bits are available, or is the implementation
13448 required to detect failure immediately? This is not an academic question. On
13449 Linux a straightforward implementation would read from /dev/random, and "When
13450 the entropy pool is empty, reads to /dev/random will block until additional
13451 environmental noise is gathered." Programmers need to know whether random_device
13452 is permitted to (or possibly even required to?) behave the same way.
13456 Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
13462 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
13463 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
13464 for some further discussion.
13468 <p><b>Proposed resolution:</b></p>
13470 Adopt the proposed resolution in
13471 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
13479 <h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
13480 <p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13481 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
13482 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
13483 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13484 <p><b>Discussion:</b></p>
13486 Paragraph 1 says that "A binomial distributon random distribution produces
13487 integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
13488 p are the parameters of the distribution. OK, that tells us what t, p, and i
13493 <p><b>Proposed resolution:</b></p>
13495 Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
13499 Portland: Subsumed by N2111.
13508 <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
13509 <p><b>Section:</b> 18.4.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13510 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-01-30 <b>Last modified:</b> 2010-10-29</p>
13511 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
13512 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13513 <p><b>Discussion:</b></p>
13515 In the synopsis, some types are identified as optional: int8_t, int16_t,
13516 and so on, consistently with C99, indeed.
13519 On the other hand, intptr_t and uintptr_t, are not marked as such and
13520 probably should, consistently with C99, 7.18.1.4.
13524 <p><b>Proposed resolution:</b></p>
13526 Change 18.4.1 [cstdint.syn]:
13529 <blockquote><pre>...
13530 typedef <i>signed integer type</i> intptr_t; <ins><i>// optional</i></ins>
13532 typedef <i>unsigned integer type</i> uintptr_t; <ins><i>// optional</i></ins>
13534 </pre></blockquote>
13538 <p><b>Rationale:</b></p>
13539 Recommend NAD and fix as editorial with the proposed resolution.
13546 <h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits<bool></h3>
13547 <p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13548 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-29 <b>Last modified:</b> 2010-10-29</p>
13549 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
13550 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13551 <p><b>Discussion:</b></p>
13553 I believe we have a bug in the resolution of:
13554 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
13559 The resolution spells out each member of <tt>numeric_limits<bool></tt>.
13560 The part I'm having a little trouble with is:
13562 <blockquote><pre>static const bool traps = false;
13563 </pre></blockquote>
13566 Should this not be implementation defined? Given:
13569 <blockquote><pre>int main()
13575 </pre></blockquote>
13578 If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be
13583 <p><b>Proposed resolution:</b></p>
13589 -3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
13590 <blockquote><pre>namespace std {
13591 template <> class numeric_limits<bool> {
13593 static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
13597 </pre></blockquote>
13601 Redmond: NAD because traps refers to values, not operations. There is no bool
13602 value that will trap.
13612 <h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
13613 <p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13614 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-02 <b>Last modified:</b> 2010-10-29</p>
13615 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13616 <p><b>Discussion:</b></p>
13618 This one, if nobody noticed it yet, seems really editorial:
13619 s/cstbool/cstdbool/
13623 <p><b>Proposed resolution:</b></p>
13628 -1- The header behaves as if it defines the additional macro defined in
13629 <tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>.
13633 Redmond: Editorial.
13643 <h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
13644 <p><b>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13645 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2010-10-29</p>
13646 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
13647 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13648 <p><b>Discussion:</b></p>
13650 I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
13651 long long we end up, essentially, with the same arguments and different
13652 return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
13653 abs(_Longlong) and abs(intmax_t), of course.
13656 Comparing sections 8.25 and 8.11, I see an important difference,
13657 however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
13658 types (rightfully, because not moved over directly from C99), whereas
13659 there is no equivalent in 8.11: the abs and div overloads for intmax_t
13660 types appear only in the synopsis and are not described anywhere, in
13661 particular no mention in 8.11.2 (at variance with 8.25.2).
13664 I'm wondering whether we really, really, want div and abs for intmax_t...
13669 <p><b>Proposed resolution:</b></p>
13674 Portland: no consensus.
13678 <p><b>Rationale:</b></p>
13680 Batavia, Bill: The <tt><cstdint></tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
13683 <blockquote><pre>intmax_t imaxabs(intmax_t i);
13684 intmax_t abs(intmax_t i);
13686 imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
13687 imaxdiv_t div(intmax_t numer, intmax_t denom);
13688 </pre></blockquote>
13691 and in TR1 8.11.2 [tr.c99.cinttypes.def]:
13696 The header defines all functions, types, and macros the same as C99
13701 This is as much definition as we give for most other C99 functions,
13702 so nothing need change. We might, however, choose to add the footnote:
13707 [<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
13708 those that take <tt>long long</tt> arguments. If so, the implementation is
13709 responsible for avoiding conflicting declarations. -- <i>end note</i>]
13713 Bellevue: NAD Editorial. Pete must add a footnote, as described below.
13719 Looks like a real problem. Dietmar suggests div() return a template
13720 type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
13721 for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
13722 need a non-normative note declaring that the types lldiv_t and imaxdiv_t
13723 may not be unique if intmax_t==_longlong.
13734 <h3><a name="558"></a>558. lib.input.iterators Defect</h3>
13735 <p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
13736 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2010-10-29</p>
13737 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
13738 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
13739 <p><b>Discussion:</b></p>
13742 24.1.1 Input iterators [lib.input.iterators]
13745 1 A class or a built-in type X satisfies the requirements of an
13746 input iterator for the value type T if the following expressions are
13747 valid, where U is the type of any specified member of type T, as
13752 There is no capital U used in table 73. There is a lowercase u, but
13753 that is clearly not meant to denote a member of type T. Also, there's
13754 no description in 24.1.1 of what lowercase a means. IMO the above
13755 should have been...Hah, a and b are already covered in 24.1/11, so maybe it
13756 should have just been:
13760 <p><b>Proposed resolution:</b></p>
13765 -1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
13766 input iterator for the value type <tt>T</tt> if the following expressions
13767 are valid<del>, where <tt>U</tt> is the type of any specified member of type
13768 <tt>T</tt>,</del> as shown in Table 73.
13772 Portland: Editorial.
13782 <h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
13783 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13784 <b>Submitter:</b> Sergey P. Derevyago <b>Opened:</b> 2006-02-17 <b>Last modified:</b> 2010-10-29</p>
13785 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
13786 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13787 <p><b>Discussion:</b></p>
13788 <h4>1. The essence of the problem.</h4>
13790 User-defined allocators without default constructor are not explicitly
13791 supported by the standard but they can be supported just like std::vector
13792 supports elements without default constructor.
13795 As a result, there exist implementations that work well with such allocators
13796 and implementations that don't.
13799 <h4>2. The cause of the problem.</h4>
13801 1) The standard doesn't explicitly state this intent but it should. In
13802 particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
13803 instances that compare non-equal. So it can similarly state the intent w.r.t.
13804 the user-defined allocators without default constructor.
13807 2) Some container operations are obviously underspecified. In particular,
13810 <blockquote><pre>template<class charT, class traits, class Allocator>
13811 basic_string<charT,traits,Allocator> operator+(
13813 const basic_string<charT,traits,Allocator>& rhs
13817 Returns: <tt>basic_string<charT,traits,Allocator>(lhs) + rhs</tt>.
13821 That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call.
13822 Obviously, the right requirement is:
13825 Returns: <tt>basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs</tt>.
13828 It seems like a lot of DRs can be submitted on this "Absent call to
13829 get_allocator()" topic.
13832 <h4>3. Proposed actions.</h4>
13834 1) Explicitly state the intent to allow for user-defined allocators without
13835 default constructor in 20.1.5 Allocator requirements.
13838 2) Correct all the places, where a correct allocator object is available
13839 through the get_allocator() call but default Allocator() gets passed instead.
13841 <h4>4. Code sample.</h4>
13843 Let's suppose that the following memory pool is available:
13845 <blockquote><pre>class mem_pool {
13847 void* allocate(size_t size);
13848 void deallocate(void* ptr, size_t size);
13850 </pre></blockquote>
13852 So the following allocator can be implemented via this pool:
13854 <blockquote><pre>class stl_allocator {
13855 mem_pool& pool;
13858 explicit stl_allocator(mem_pool& mp) : pool(mp) {}
13859 stl_allocator(const stl_allocator& sa) : pool(sa.pool) {}
13860 template <class U>
13861 stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {}
13862 ~stl_allocator() {}
13864 pointer allocate(size_type n, std::allocator<void>::const_pointer = 0)
13866 return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0;
13869 void deallocate(pointer p, size_type n)
13871 if (n!=0) pool.deallocate(p, n*sizeof(T));
13876 </pre></blockquote>
13878 Then the following code works well on some implementations and doesn't work on
13881 <blockquote><pre>typedef basic_string<char, char_traits<char>, stl_allocator<char> >
13884 tl_string s1("abc", stl_allocator<int>(mp));
13885 printf("(%s)\n", ("def"+s1).c_str());
13886 </pre></blockquote>
13888 In particular, on some implementations the code can't be compiled without
13889 default stl_allocator() constructor.
13892 The obvious way to solve the compile-time problems is to intentionally define
13893 a NULL pointer dereferencing default constructor
13895 <blockquote><pre>stl_allocator() : pool(*static_cast<mem_pool*>(0)) {}
13896 </pre></blockquote>
13898 in a hope that it will not be called. The problem is that it really gets
13899 called by operator+(const char*, const string&) under the current 21.3.7.1p2
13904 <p><b>Proposed resolution:</b></p>
13909 <p><b>Rationale:</b></p>
13911 Recommend NAD. <tt>operator+()</tt> with <tt>string</tt> already requires the desired
13912 semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
13920 <h3><a name="568"></a>568. log2 overloads missing</h3>
13921 <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13922 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-03-07 <b>Last modified:</b> 2010-10-29</p>
13923 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13924 <p><b>Discussion:</b></p>
13926 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
13930 Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
13938 We agree this has been fixed in the Working Draft.
13943 <p><b>Proposed resolution:</b></p>
13945 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
13953 <h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
13954 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
13955 <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-03-10 <b>Last modified:</b> 2010-10-29</p>
13956 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
13957 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
13958 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
13959 <p><b>Discussion:</b></p>
13961 Section: 27.4.4.3 [lib.iostate.flags]
13967 <blockquote><pre>void clear(iostate <i>state</i> = goodbit);
13968 </pre></blockquote>
13970 <i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
13971 otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
13976 The postcondition "rdstate()==state|ios_base::badbit" is parsed as
13977 "(rdstate()==state)|ios_base::badbit", which is probably what the
13984 <p><b>Rationale:</b></p>
13992 <h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
13993 <p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13994 <b>Submitter:</b> Jack Reeves <b>Opened:</b> 2006-04-06 <b>Last modified:</b> 2010-10-29</p>
13995 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
13996 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13997 <p><b>Discussion:</b></p>
13999 Currently, the Standard Library specifies only a declaration for template class
14000 char_traits<> and requires the implementation provide two explicit
14001 specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard
14002 should require explicit specializations for all built-in character types, i.e.
14003 char, wchar_t, unsigned char, and signed char.
14006 I have put together a paper
14007 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
14008 that describes this in more detail and
14009 includes all the necessary wording.
14012 Portland: Jack will rewrite
14013 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
14014 to propose a primary template that will work with other integral types.
14018 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
14029 We suggest that Jack be asked about the status of his paper, and if it
14030 is not forthcoming, the work-item be assigned to someone else. If no one
14031 steps forward to do the paper before the next meeting, we propose to
14032 make this NAD without further discussion. We leave this Open for now,
14033 but our recommendation is NAD.
14036 Note: the issue statement should be updated, as the Toronto comment has
14037 already been resolved. E.g., char_traits specializations for char16_t
14038 and char32_t are now in the working paper.
14048 Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
14052 <p><b>Proposed resolution:</b></p>
14059 <h3><a name="571"></a>571. Update C90 references to C99?</h3>
14060 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
14061 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-08 <b>Last modified:</b> 2010-10-29</p>
14062 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
14063 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
14064 <p><b>Discussion:</b></p>
14066 1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
14067 9899:1990, Programming languages - C. Should that be changed to ISO/IEC
14071 What impact does this have on the library?
14075 <p><b>Proposed resolution:</b></p>
14077 In 1.2/1 [intro.refs] of the WP, change:
14081 <li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
14087 <p><b>Rationale:</b></p>
14088 Recommend NAD, fixed editorially.
14095 <h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
14096 <p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14097 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-04-11 <b>Last modified:</b> 2010-10-29</p>
14098 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
14099 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14100 <p><b>Discussion:</b></p>
14102 In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
14103 variate_generator has been eliminated. Then in full committee we voted to give
14104 this issue WP status (mistakenly).
14108 <p><b>Proposed resolution:</b></p>
14110 Strike the proposed resolution of issue 507.
14113 post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longer
14114 exists in the current WD.
14119 <p><b>Rationale:</b></p>
14121 NAD. Will be moot once
14122 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
14131 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
14132 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14133 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-12 <b>Last modified:</b> 2010-10-29</p>
14134 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
14135 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14136 <p><b>Discussion:</b></p>
14138 There are two deficiencies related to file sizes:
14141 <li>It doesn't appear that the Standard Library is specified in
14142 a way that handles modern file sizes, which are often too
14143 large to be represented by an unsigned long.</li>
14145 <li>The std::fpos class does not currently have the ability to
14146 set/get file positions.</li>
14149 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
14152 <li>Defining fpos_t be long long, which is large enough to
14153 represent any file position likely in the foreseeable future.</li>
14155 <li>Adding member functions to class fpos. For example,
14156 <blockquote><pre>fpos_t seekpos() const;
14157 </pre></blockquote>
14161 Because there are so many types relating to file positions and offsets (fpos_t,
14162 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
14163 perhaps more), it is difficult to know if the Dinkumware extensions are
14164 sufficient. But they seem a useful starting place for discussions, and they do
14165 represent existing practice.
14169 Kona (2007): We need a paper. It would be nice if someone proposed
14170 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
14171 these definitions are horrible. Proposed Disposition: Open
14182 This is the subject of paper N2926.
14185 If we choose to take any action, we will move the paper, so the issue can be closed.
14194 <p><b>Proposed resolution:</b></p>
14203 <h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
14204 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14205 <b>Submitter:</b> JoaquÃn M López Muñoz <b>Opened:</b> 2006-06-13 <b>Last modified:</b> 2010-11-29</p>
14206 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
14207 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
14208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14209 <p><b>Discussion:</b></p>
14212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
14213 for full discussion.
14217 2009-12-11 Paolo opens:
14222 I'm asking for DR 579 to be re-opened, basing on recent discussions on the
14223 library reflector, see Message c++std-lib-26040 and replies.
14227 2010-02-07 Paolo updates wording.
14232 As pointed out by Chris in c++std-lib-26040, that an
14233 <tt>erase(unordered_container, iterator)</tt> returning an <tt>iterator</tt> can
14234 easily implemented in user code, if needed; that actually returning an
14235 <tt>iterator</tt> costs nothing for the overload taking two <tt>iterator</tt>s,
14236 thus that proposed change is only for consistency; that
14237 <tt>forward_list::erase_after</tt> also returns <tt>void</tt> (for different
14238 reasons, granted, but isn't that any "<tt>erase</tt>" function in the containers
14239 uniformly returns an <tt>iterator</tt>); that, also in thread started by Chris'
14240 message, Alberto pointed out that the proxy idea isn't a good one; that users
14241 both of the GNU and Boost implementations are reporting serious performance
14242 problems with the current version returning an <tt>iterator</tt>.
14246 2010-02-07 Original wording saved here:
14250 <blockquote class="note">
14256 The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an
14257 iterator. This is, however, in contrast with the equivalent requirements for other
14258 standard containers.
14266 <tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested:
14267 the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so
14271 <blockquote><pre>iterator q1=a.erase(q);
14272 </pre></blockquote>
14275 works as expected, while
14278 <blockquote><pre>a.erase(q);
14279 </pre></blockquote>
14282 does not ever invoke the conversion-to-iterator operator, thus avoiding the associated
14283 computation. To allow this technique, some sections of TR1 along the line "return value
14284 is an iterator..." should be changed to "return value is an unspecified object implicitly
14285 convertible to an iterator..." Although this trick is expected to work transparently, it can
14286 have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic
14293 2010-03-27 JoaquÃn adds:
14299 Signature of <tt>iterator erase(const_iterator)</tt> should be changed to <tt>void
14300 erase(const_iterator)</tt>. If this is not viable an acceptable tradeoff
14301 could be to make the return type of <tt>erase(const_iterator)</tt>
14302 <i>implementation defined</i>.
14306 The standard should allow implementations of unordered associative
14307 containers using either singly or doubly linked lists.
14308 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
14309 proves that singly-linked lists implementations cannot provide the required
14310 complexity for <tt>iterator erase(const_iterator)</tt>. Thus, some action is
14311 needed to allow both implementations.
14315 Option 1: Changing the required complexity from O(1) to O(log n). This option
14316 merely masks a design flaw. Users are forcefully penalized for what they don't
14317 use (the returned iterator). Besides, they would have to learn about the
14318 pathological (yet very real) situations where using <tt>erase</tt> can lead to
14319 quadratic performance. Two out of these three objections remain even if some
14320 alternative member function like <tt>void quick_erase(const_iterator)</tt> is
14321 thrown in to the interface.
14325 Some objections have been expressed to changing return type of <tt>erase</tt> to
14326 <tt>void</tt>, arguing that it would break current existing practice with
14327 standard library implementations based on doubly-linked lists, where the problem
14328 does not occur. However implementations based on drafts should not block the
14329 resolution of a serious design issue, more so when the issue will hurt future
14330 users of C++, as it's happening already.
14334 Option 2: Make <tt>erase</tt> return type <i>implementation defined</i>. There's
14335 a possible tradeoff with the objectors above consisting in changing the
14336 signature to <i>implementation defined</i> <tt>erase(iterator)</tt>, so that
14337 returning an iterator is indeed a valid extension. To this it can be argued that
14338 this would make implementantions returning an iterator look as somehow promoting
14339 proprietary extensions: this in my opinion is not a valid argument since those
14340 implementations are <em>already</em> extending the required interface by
14341 providing bidirectional iterators (just forward iterators are required).
14352 The issue was lengthy discussed and implementation experience was demonstrated that a non-void return
14353 type is implementable for both single-linked and double-linked lists without loss of efficiency.
14357 By a 12-1-1-0 poll voted to keep the return type of erase as <tt>iterator</tt> instead of
14358 <tt>void</tt> and a second 0-0-3-10 poll rejected the additional proposal to add a
14359 <tt>quick_erase</tt> returning <tt>void</tt>, thus LWG decided for NAD.
14364 <p><b>Rationale:</b></p>
14367 No consensus for a change.
14372 <p><b>Proposed resolution:</b></p>
14379 <h3><a name="580"></a>580. unused allocator members</h3>
14380 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
14381 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2010-10-29</p>
14382 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
14383 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
14384 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
14385 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
14386 <p><b>Discussion:</b></p>
14389 C++ Standard Library templates that take an allocator as an argument
14390 are required to call the <code>allocate()</code> and
14391 <code>deallocate()</code> members of the allocator object to obtain
14392 storage. However, they do not appear to be required to call any other
14393 allocator members such as <code>construct()</code>,
14394 <code>destroy()</code>, <code>address()</code>, and
14395 <code>max_size()</code>. This makes these allocator members less than
14396 useful in portable programs.
14401 It's unclear to me whether the absence of the requirement to use these
14402 allocator members is an unintentional omission or a deliberate
14403 choice. However, since the functions exist in the standard allocator
14404 and since they are required to be provided by any user-defined
14405 allocator I believe the standard ought to be clarified to explictly
14406 specify whether programs should or should not be able to rely on
14407 standard containers calling the functions.
14412 I propose that all containers be required to make use of these
14417 Batavia: We support this resolution. Martin to provide wording.
14421 pre-Oxford: Martin provided wording.
14426 2009-04-28 Pablo adds:
14431 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
14432 (scoped allocators),
14433 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
14434 (allocator concepts), and
14435 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
14436 (allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
14437 So, I would add a note to that affect and re-class the defect as belonging
14438 to section 23.2.1 [container.requirements.general].
14447 The comment in the description of this issue that this "would be"
14448 rendered editorial by the adoption of N2257 is confusing. It appears
14449 that N2257 was never adopted.
14453 2009-10 Santa Cruz:
14458 NAD Editorial. Addressed by
14459 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
14464 <p><b>Proposed resolution:</b></p>
14467 Specifically, I propose to change 23.2 [container.requirements],
14473 -9- Copy constructors for all container types defined in this clause
14474 <ins>that are parametrized on <code>Allocator</code></ins> copy
14475 <del>an</del><ins>the</ins> allocator argument from their respective
14478 All other constructors for these container types take a<del>n</del>
14479 <ins>const</ins> <code>Allocator&</code> argument (20.1.6), an
14480 allocator whose <code>value_type</code> is the same as the container's
14481 <code>value_type</code>.
14483 A copy of this argument <del>is</del><ins>shall be</ins> used for any
14484 memory allocation <ins> and deallocation</ins> performed<del>,</del>
14485 by these constructors and by all member functions<del>,</del> during
14486 the lifetime of each container object. <ins>Allocation shall be
14487 performed "as if" by calling the <code>allocate()</code> member
14488 function on a copy of the allocator object of the appropriate type
14489 <sup>New Footnote)</sup>, and deallocation "as if" by calling
14490 <code>deallocate()</code> on a copy of the same allocator object of
14491 the corresponding type.</ins>
14493 <ins>A copy of this argument shall also be used to construct and
14494 destroy objects whose lifetime is managed by the container, including
14495 but not limited to those of the container's <code>value_type</code>,
14496 and to obtain their address. All objects residing in storage
14497 allocated by a container's allocator shall be constructed "as if" by
14498 calling the <code>construct()</code> member function on a copy of the
14499 allocator object of the appropriate type. The same objects shall be
14500 destroyed "as if" by calling <code>destroy()</code> on a copy of the
14501 same allocator object of the same type. The address of such objects
14502 shall be obtained "as if" by calling the <code>address()</code> member
14503 function on a copy of the allocator object of the appropriate
14506 <ins>Finally, a copy of this argument shall be used by its container
14507 object to determine the maximum number of objects of the container's
14508 <code>value_type</code> the container may store at the same time. The
14509 container member function <code>max_size()</code> obtains this number
14510 from the value returned by a call to
14511 <code>get_allocator().max_size()</code>.</ins>
14513 In all container types defined in this clause <ins>that are
14514 parametrized on <code>Allocator</code></ins>, the member
14515 <code>get_allocator()</code> returns a copy of the
14516 <code>Allocator</code> object used to construct the
14517 container.<sup>258)</sup>
14520 New Footnote: This type may be different from <code>Allocator</code>:
14521 it may be derived from <code>Allocator</code> via
14522 <code>Allocator::rebind<U>::other</code> for the appropriate
14523 type <code>U</code>.
14528 The proposed wording seems cumbersome but I couldn't think of a better
14529 way to describe the requirement that containers use their
14530 <code>Allocator</code> to manage only objects (regardless of their
14531 type) that persist over their lifetimes and not, for example,
14532 temporaries created on the stack. That is, containers shouldn't be
14533 required to call <code>Allocator::construct(Allocator::allocate(1),
14534 elem)</code> just to construct a temporary copy of an element, or
14535 <code>Allocator::destroy(Allocator::address(temp), 1)</code> to
14536 destroy temporaries.
14542 Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>.
14547 post Oxford: This would be rendered NAD Editorial by acceptance of
14548 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
14556 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
14557 <p><b>Section:</b> 20.9.8.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14558 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2010-10-29</p>
14559 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
14560 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14561 <p><b>Discussion:</b></p>
14563 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a></p>
14566 The specialized algorithms [lib.specialized.algorithms] are specified
14567 as having the general effect of invoking the following expression:
14571 new (static_cast<void*>(&*i))
14572 typename iterator_traits<ForwardIterator>::value_type (x)
14577 This expression is ill-formed when the type of the subexpression
14578 <code>&*i</code> is some volatile-qualified <code>T</code>.
14583 Batavia: Lack of support for proposed resolution but agree there is a
14584 defect. Howard to look at wording. Concern that move semantics
14585 properly expressed if iterator returns rvalue.
14591 2009-06-17 Pablo adds:
14597 <p>Propose that Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a> be closed NAD.</p>
14599 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a> asks that <tt>uninitialized_copy</tt>,
14600 <tt>uninitialized_fill</tt>, and <tt>uninitialized_fill_n</tt> should be
14601 well-formed if the result type is volatile. My feeling is that the
14602 standard does not, and should not, guarantee any useful behavior when
14603 constructors are invoked on volatile storage, so making it syntactically
14604 legal to call <tt>uninitialized_copy</tt> on volatile storage is not useful. A
14605 possible editorial change would be to put my previous sentence into a
14606 non-normative note.
14609 Note that the three sections starting with 20.9.8.2 [uninitialized.copy] do not
14610 yet have concepts. Here's a first crack at the first one:
14612 <blockquote><pre>template <InputIterator InIter, OutputIterator OutIter>
14613 requires ExplicitConvertible<HasDereference<OutIter::reference>::result,
14614 OutIter::value_type&>
14615 && Convertible<OutIter::value_type*, void*>
14616 && ExplicitConvertible<OutIter::value_type, InIter::reference>
14617 OutIter uninitialized_copy(InIter first, InIter last, OutIter result);
14623 <blockquote><pre>while (first != last) {
14624 typedef OutIter::value_type value_type;
14625 value_type& outRef = static_cast<value_type&>(*result++);
14626 ::new (static_cast<void*>(addressof(outRef))) value_type(*first++);
14628 </pre></blockquote>
14637 <li>This definition is actually LESS constrained than in C++03 because
14638 there is no requirement that the result be a forward iterator.
14642 OutIter returns a proxy type with an overloaded operator&, this
14643 definition probably won't compile. Lifting this limitation while
14644 allowing value_type to have an overloaded operator& would be hard, but
14645 is probably possible with careful overloading. I'm not sure it's worth
14649 This definition retains the prohibition on the use of volatile types for the result.
14662 We don't deal with volatile in the library.
14665 Jim: should we state that explicitly somewhere?
14668 Beman: you might argue that clause 17 should say something about
14669 volatile. However, if you want to raise we argument, we should open it
14670 as a separate issue and consult with experts on concurrency.
14673 Hinnant: actually, some library components do handle volatile, so we'd
14674 need to be very careful about what we say in clause 17.
14677 No objection to NAD.
14686 <p><b>Proposed resolution:</b></p>
14689 In order to allow these algorithms to operate on volatile storage I
14690 propose to change the expression so as to make it well-formed even for
14691 pointers to volatile types. Specifically, I propose the following
14692 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
14698 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
14699 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
14701 for (; first != last; ++result, ++first)
14702 new (static_cast<void*>(const_cast<pointer>(&*result))
14703 value_type (*first);
14708 change 20.6.4.2, p1 to read
14714 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
14715 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
14717 for (; first != last; ++result, ++first)
14718 new (static_cast<void*>(const_cast<pointer>(&*first))
14724 and change 20.6.4.3, p1 to read
14730 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
14731 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
14733 for (; n--; ++first)
14734 new (static_cast<void*>(const_cast<pointer>(&*first))
14740 In addition, since there is no partial specialization for
14741 <code>iterator_traits<volatile T*></code> I propose to add one
14742 to parallel such specialization for <const T*>. Specifically, I
14743 propose to add the following text to the end of 24.3.1, p3:
14748 and for pointers to volatile as
14753 template<class T> struct iterator_traits<volatile T*> {
14754 typedef ptrdiff_t difference_type;
14755 typedef T value_type;
14756 typedef volatile T* pointer;
14757 typedef volatile T& reference;
14758 typedef random_access_iterator_tag iterator_category;
14765 Note that the change to <code>iterator_traits</code> isn't necessary
14766 in order to implement the specialized algorithms in a way that allows
14767 them to operate on volatile strorage. It is only necesassary in order
14768 to specify their effects in terms of <code>iterator_traits</code> as
14769 is done here. Implementations can (and some do) achieve the same
14770 effect by means of function template overloading.
14778 <h3><a name="583"></a>583. div() for unsigned integral types</h3>
14779 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14780 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2010-10-29</p>
14781 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
14782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14783 <p><b>Discussion:</b></p>
14785 There is no div() function for unsigned integer types.
14788 There are several possible resolutions. The simplest one is noted below. Other
14789 possibilities include a templated solution.
14793 <p><b>Proposed resolution:</b></p>
14795 Add to 26.7 [lib.c.math] paragraph 8:
14798 <blockquote><pre>struct udiv_t div(unsigned, unsigned);
14799 struct uldiv_t div(unsigned long, unsigned long);
14800 struct ulldiv_t div(unsigned long long, unsigned long long);
14801 </pre></blockquote>
14805 <p><b>Rationale:</b></p>
14806 Toronto: C99 does not have these unsigned versions because
14807 the signed version exist just to define the implementation-defined behavior
14808 of signed integer division. Unsigned integer division has no implementation-defined
14809 behavior and thus does not need this treatment.
14816 <h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
14817 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14818 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2010-10-29</p>
14819 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
14820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14821 <p><b>Discussion:</b></p>
14823 There is no pow() function for any integral type.
14827 <p><b>Proposed resolution:</b></p>
14829 Add something like:
14832 <blockquote><pre>template< typename T>
14833 T power( T x, int n );
14834 // requires: n >=0
14835 </pre></blockquote>
14838 <p><b>Rationale:</b></p>
14839 Toronto: We already have double pow(integral, integral) from 26.8 [c.math] p11.
14846 <h3><a name="585"></a>585. facet error reporting</h3>
14847 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14848 <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2010-10-29</p>
14849 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
14850 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14851 <p><b>Discussion:</b></p>
14854 Section 22.2, paragraph 2 requires facet <code>get()</code> members
14855 that take an <code>ios_base::iostate&</code> argument,
14856 <code><i>err</i></code>, to ignore the (initial) value of the
14857 argument, but to set it to <code>ios_base::failbit</code> in case of a
14863 We believe there are a few minor problems with this blanket
14864 requirement in conjunction with the wording specific to each
14865 <code>get()</code> member function.
14870 First, besides <code>get()</code> there are other member functions
14871 with a slightly different name (for example,
14872 <code>get_date()</code>). It's not completely clear that the intent of
14873 the paragraph is to include those as well, and at least one
14874 implementation has interpreted the requirement literally.
14879 Second, the requirement to "set the argument to
14880 <code>ios_base::failbit</code> suggests that the functions are not
14881 permitted to set it to any other value (such as
14882 <code>ios_base::eofbit</code>, or even <code>ios_base::eofbit |
14883 ios_base::failbit</code>).
14888 However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and
14889 p6 (<code>bool</code> parsing) specifies that the <code>do_get</code>
14890 functions perform <code><i>err</i> |= ios_base::eofbit</code>, which
14891 contradicts the earlier requirement to ignore <i>err</i>'s initial
14897 22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code>
14898 facet's <code>do_get</code> member functions) also specifies that
14899 <code><i>err</i></code>'s initial value be used to compute the final
14900 value by ORing it with either <code>ios_base::failbit</code> or
14901 with<code>ios_base::eofbit | ios_base::failbit</code>.
14916 <p><b>Proposed resolution:</b></p>
14919 We believe the intent is for all facet member functions that take an
14920 <code>ios_base::iostate&</code> argument to:
14926 ignore the initial value of the <code><i>err</i></code> argument,
14931 reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior
14932 to any further processing,
14937 and set either <code>ios_base::eofbit</code>, or
14938 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
14939 appropriate, in response to reaching the end-of-file or on parse
14946 To that effect we propose to change 22.2, p2 as follows:
14951 The <i>put</i><del>()</del> members make no provision for error
14952 reporting. (Any failures of the OutputIterator argument must be
14953 extracted from the returned iterator.) <ins>Unless otherwise
14954 specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins>
14955 take an <code>ios_base::iostate&</code> argument <del>whose value
14956 they ignore, but set to ios_base::failbit in case of a parse
14957 error.</del><ins>, <code><i>err</i></code>, start by evaluating
14958 <code>err = ios_base::goodbit</code>, and may subsequently set
14959 <i>err</i> to either <code>ios_base::eofbit</code>, or
14960 <code>ios_base::failbit</code>, or <code>ios_base::eofbit |
14961 ios_base::failbit</code> in response to reaching the end-of-file or in
14962 case of a parse error, or both, respectively.</ins>
14968 Kona (2007): We need to change the proposed wording to clarify that the
14969 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
14970 Proposed Disposition: Open
14977 <h3><a name="587"></a>587. iststream ctor missing description</h3>
14978 <p><b>Section:</b> D.9.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
14979 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2010-10-29</p>
14980 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
14981 <p><b>Discussion:</b></p>
14984 The <code>iststream(char*, streamsize)</code> ctor is in the class
14985 synopsis in D.7.2 but its signature is missing in the description
14986 below (in D.7.2.1).
14991 <p><b>Proposed resolution:</b></p>
14994 This seems like a simple editorial issue and the missing signature can
14995 be added to the one for <code>const char*</code> in paragraph 2.
15000 post Oxford: Noted that it is already fixed in
15001 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
15010 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
15011 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15012 <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18 <b>Last modified:</b> 2010-10-29</p>
15013 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
15014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15015 <p><b>Discussion:</b></p>
15017 The wording used for section 23.2.1 [lib.array] seems to be subtly
15018 ambiguous about zero sized arrays (N==0). Specifically:
15021 * "An instance of array<T, N> stores N elements of type T, so that
15025 Does this imply that a zero sized array object stores 0 elements, i.e.
15026 that it cannot store any element of type T? The next point clarifies
15027 the rationale behind this question, basically how to implement begin()
15031 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
15032 end() == unique value."
15035 What does "unique" mean in this context? Let's consider the following
15036 possible implementations, all relying on a partial specialization:
15038 <blockquote><pre>a)
15039 template< typename T >
15040 class array< T, 0 > {
15045 { return iterator( reinterpret_cast< T * >( this ) ); }
15049 </pre></blockquote>
15051 This has been used in boost, probably intending that the return value
15052 had to be unique to the specific array object and that array couldn't
15053 store any T. Note that, besides relying on a reinterpret_cast, has
15054 (more than potential) alignment problems.
15056 <blockquote><pre>b)
15057 template< typename T >
15058 class array< T, 0 > {
15063 { return iterator( &t ); }
15067 </pre></blockquote>
15069 This provides a value which is unique to the object and to the type of
15070 the array, but requires storing a T. Also, it would allow the user to
15071 mistakenly provide an initializer list with one element.
15074 A slight variant could be returning *the* null pointer of type T
15076 <blockquote><pre> return static_cast<T*>(0);
15077 </pre></blockquote>
15079 In this case the value would be unique to the type array<T, 0> but not
15080 to the objects (all objects of type array<T, 0> with the same value
15081 for T would yield the same pointer value).
15084 Furthermore this is inconsistent with what the standard requires from
15085 allocation functions (see library issue 9).
15088 c) same as above but with t being a static data member; again, the
15089 value would be unique to the type, not to the object.
15092 d) to avoid storing a T *directly* while disallowing the possibility
15093 to use a one-element initializer list a non-aggregate nested class
15096 <blockquote><pre> struct holder { holder() {} T t; } h;
15097 </pre></blockquote>
15099 and then begin be defined as
15101 <blockquote><pre> iterator begin() { return &h.t; }
15102 </pre></blockquote>
15104 But then, it's arguable whether the array stores a T or not.
15105 Indirectly it does.
15108 -----------------------------------------------------
15111 Now, on different issues:
15114 * what's the effect of calling assign(T&) on a zero-sized array? There
15115 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
15116 p4 (I would also suggest to move that bullet to section 23.2.1.5
15117 [lib.array.zero], for locality of reference)
15120 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
15121 inconsistent with that of other sequences: that's not a problem in
15122 itself, but compare it for instance with "A vector is a kind of
15123 sequence that supports random access iterators"; though the intent is
15124 obvious one might argue that the wording used for arrays doesn't tell
15125 what an array is, and relies on the reader to infer that it is what
15126 the <array> header defines.
15129 * it would be desiderable to have a static const data member of type
15130 std::size_t, with value N, for usage as integral constant expression
15133 * section 23.1 [lib.container.requirements] seem not to consider
15134 fixed-size containers at all, as it says: "[containers] control
15135 allocation and deallocation of these objects [the contained objects]
15136 through constructors, destructors, *insert and erase* operations"
15139 * max_size() isn't specified: the result is obvious but, technically,
15140 it relies on table 80: "size() of the largest possible container"
15141 which, again, doesn't seem to consider fixed size containers
15145 2009-05-29 Daniel adds:
15153 star bullet 1 ("what's the effect of calling <tt>assign(T&)</tt> on a
15154 zero-sized array?[..]");
15157 <tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
15158 defined in terms of
15159 the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
15164 star bullet 3 ("it would be desiderable to have a static const data
15168 It seems that <tt>tuple_size<array<T, N> >::value</tt> as of 23.3.1.8 [array.tuple] does
15169 provide this functionality now.
15182 Alisdair to address by the next meeting, or declare NAD.
15185 Moved to Tentatively NAD.
15200 <p><b>Proposed resolution:</b></p>
15206 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
15207 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
15208 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
15216 <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
15217 <p><b>Section:</b> 20.7 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
15218 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-08-10 <b>Last modified:</b> 2010-10-29</p>
15219 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
15220 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
15221 <p><b>Discussion:</b></p>
15223 20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
15224 traits implementers that is not needed in C++0x. It includes the wording:
15228 [<i>Note:</i> the latitude granted to implementers in this clause is temporary,
15229 and is expected to be removed in future revisions of this document. -- <i>end note</i>]
15234 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
15235 also has the intent of removing this wording from the WP.
15240 <p><b>Proposed resolution:</b></p>
15242 Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
15246 post-Oxford: Recommend NAD Editorial. This resolution is now in the
15247 current working draft.
15257 <h3><a name="591"></a>591. Misleading "built-in</h3>
15258 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
15259 <b>Submitter:</b> whyglinux <b>Opened:</b> 2006-08-08 <b>Last modified:</b> 2010-10-29</p>
15260 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
15261 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
15262 <p><b>Discussion:</b></p>
15264 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
15268 "For built-in integer types, the number of non-sign bits in the
15273 26.1 Numeric type requirements [lib.numeric.requirements]
15278 "In other words, value types. These include built-in arithmetic types,
15279 pointers, the library class complex, and instantiations of valarray for
15284 Integer types (which are bool, char, wchar_t, and the signed and
15285 unsigned integer types) and arithmetic types (which are integer and
15286 floating types) are all built-in types and thus there are no
15287 non-built-in (that is, user-defined) integer or arithmetic types. Since
15288 the redundant "built-in" in the above 2 sentences can mislead that
15289 there may be built-in or user-defined integer and arithmetic types
15290 (which is not correct), the "built-in" should be removed.
15294 <p><b>Proposed resolution:</b></p>
15296 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
15300 "For <del>built-in</del> integer types, the number of non-sign bits in the
15305 26.1 Numeric type requirements [lib.numeric.requirements]
15310 "In other words, value types. These include <del>built-in</del> arithmetic types,
15311 pointers, the library class complex, and instantiations of valarray for
15316 <p><b>Rationale:</b></p>
15318 Recommend NAD / Editorial. The proposed resolution is accepted as editorial.
15326 <h3><a name="592"></a>592. Incorrect treatment of rdbuf()->close() return type</h3>
15327 <p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
15328 <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2006-08-17 <b>Last modified:</b> 2010-10-29</p>
15329 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
15330 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
15331 <p><b>Discussion:</b></p>
15333 I just spotted a minor problem in 27.8.1.7
15334 [lib.ifstream.members] para 4 and also 27.8.1.13
15335 [lib.fstream.members] para 4. In both places it says:
15341 Effects: Calls rdbuf()->close() and, if that function returns false, ...
15345 However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
15346 filebuf on success, null on failure, so I think it is meant to
15347 say "if that function returns a null pointer". Oddly, it is
15348 correct for basic_ofstream.
15352 <p><b>Proposed resolution:</b></p>
15354 Change 27.9.1.9 [ifstream.members], p5:
15358 <i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function
15359 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
15360 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
15365 Change 27.9.1.17 [fstream.members], p5:
15369 <i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function
15370 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
15371 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
15378 Kona (2007): Proposed Disposition: NAD, Editorial
15386 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
15387 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15388 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05 <b>Last modified:</b> 2010-10-29</p>
15389 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
15390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15391 <p><b>Discussion:</b></p>
15393 In a private email, Daveed writes:
15397 I am not familiar with the C TR, but my guess is that the
15398 class type approach still won't match a built-in type
15399 approach because the notion of "promotion" cannot be
15400 emulated by user-defined types.
15403 Here is an example:
15408 S(_Decimal32 const&); // Converting constructor
15412 void f(_Decimal64);
15414 void g(_Decimal32 d) {
15421 If _Decimal32 is a built-in type, the call f(d) will likely
15422 resolve to f(_Decimal64) because that requires only a
15423 promotion, whereas f(S) requires a user-defined conversion.
15426 If _Decimal32 is a class type, I think the call f(d) will be
15427 ambiguous because both the conversion to _Decimal64 and the
15428 conversion to S will be user-defined conversions with neither
15429 better than the other.
15436 In general, a library of arithmetic types cannot exactly emulate the behavior of the intrinsic numeric types. There are several ways to tell whether an implementation of the decimal types uses compiler intrinisics or a library. For example:
15438 <pre> _Decimal32 d1;
15439 d1.operator+=(5); // If d1 is a builtin type, this won't compile.
15442 In preparing the decimal TR, we have three options:
15445 <li>require that the decimal types be class types</li>
15446 <li>require that the decimal types be builtin types, like float and double</li>
15447 <li>specify a library of class types, but allow enough implementor latitude that a conforming implementation could instead provide builtin types</li>
15450 We decided as a group to pursue option #3, but that approach implies that implementations may not agree on the semantics of certain use cases (first example, above), or on whether certain other cases are well-formed (second example). Another potentially important problem is that, under the present definition of POD, the decimal classes are not POD types, but builtins will be.
15453 Note that neither example above implies any problems with respect to C-to-C++ compatibility, since neither example can be expressed in C.
15463 Decimal numeric types may either be builtin types or library types. We
15464 only intend to specify the common subset of behaviors of the two
15465 implementation approaches. The front matter of the Decimal TR says this
15475 <p><b>Proposed resolution:</b></p>
15482 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
15483 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15484 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2010-10-29</p>
15485 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
15486 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15487 <p><b>Discussion:</b></p>
15489 In c++std-lib-17205, Martin writes:
15492 ...was it a deliberate design choice to make narrowing assignments ill-formed while permitting narrowing compound assignments? For instance:
15494 <pre> decimal32 d32;
15501 In c++std-lib-17229, Robert responds:
15504 It is a vestige of an old idea that I forgot to remove from the paper. Narrowing assignments should be permitted. The bug is that the converting constructors that cause narrowing should not be explicit. Thanks for pointing this out.
15514 The current state of the Decimal TR is the result of a deliberate design
15515 decision that has been examined many times.
15523 <p><b>Proposed resolution:</b></p>
15525 1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
15527 <pre> // <i>3.2.2.2 conversion from floating-point type:</i>
15528 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
15529 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
15532 2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
15535 3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
15537 <pre> // <i>3.2.3.2 conversion from floating-point type:</i>
15538 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
15541 4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
15545 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
15554 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
15555 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15556 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-05 <b>Last modified:</b> 2010-10-29</p>
15557 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
15558 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15559 <p><b>Discussion:</b></p>
15561 This is based on N2134, where 21.3.1/2 states:
15562 "... The Allocator object used shall be a copy of the Allocator object
15563 passed to the basic_string object's constructor or, if the constructor does
15564 not take an Allocator argument, a copy of a default-constructed Allocator
15568 Section 21.3.2/1 lists two constructors:
15570 <blockquote><pre>basic_string(const basic_string<charT,traits,Allocator>& str );
15572 basic_string(const basic_string<charT,traits,Allocator>& str ,
15573 size_type pos , size_type n = npos,
15574 const Allocator& a = Allocator());
15575 </pre></blockquote>
15577 and then says "In the first form, the Allocator value used is copied from
15578 str.get_allocator().", which isn't an option according to 21.3.1.
15581 Batavia: We need blanket statement to the effect of:
15586 <li>If an allocator is passed in, use it, or,</li>
15587 <li>If a string is passed in, use its allocator.</li>
15590 Review constructors and functions that return a string; make sure we follow these
15591 rules (substr, operator+, etc.). Howard to supply wording.
15596 Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not
15597 consistent with 23.2 [container.requirements], p9 which says in part:
15599 </i></p><blockquote><i>
15600 All other constructors for these container types take an
15601 <tt>Allocator&</tt> argument (20.1.2), an allocator whose value type
15602 is the same as the container's value type. A copy of this argument is
15603 used for any memory allocation performed, by these constructors and by
15604 all member functions, during the lifetime of each container object.
15605 </i></blockquote><i>
15610 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
15625 <p><b>Proposed resolution:</b></p>
15634 <h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
15635 <p><b>Section:</b> 21.7 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
15636 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-11 <b>Last modified:</b> 2010-10-29</p>
15637 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
15638 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
15639 <p><b>Discussion:</b></p>
15641 In the current draft N2134, 21.4/1 says
15644 "Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers <cctype>,
15645 <cwctype>, <cstring>, <cwchar>, and <cstdlib> (character conversions),
15649 Here footnote 229 applies to table 62, not table 63.
15652 Also, footnote 230 lists the new functions in table 63, "atoll, strtoll,
15653 strtoull, strtof, and strtold added by TR1". However, strtof is not present
15658 <p><b>Proposed resolution:</b></p>
15663 <p><b>Rationale:</b></p>
15665 Recommend NAD, editorial. Send to Pete.
15673 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
15674 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15675 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30 <b>Last modified:</b> 2010-10-29</p>
15676 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
15677 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15678 <p><b>Discussion:</b></p>
15680 The <tt><array></tt> header is given under 23.3 [sequences].
15681 23.3.1 [array]/paragraph 3 says:
15684 "Unless otherwise specified, all array operations are as described in
15685 23.2 [container.requirements]".
15688 However, array isn't mentioned at all in section 23.2 [container.requirements].
15689 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
15690 that std::array does not have in 23.3.1 [array].
15693 Also, Table 83 "Optional sequence operations" lists several operations that
15694 std::array does have, but array isn't mentioned.
15704 The real issue seems to be different than what is described here.
15705 Non-normative text says that std::array is a sequence container, but
15706 there is disagreement about what that really means. There are two
15707 possible interpretations:
15711 a sequence container is one that satisfies all sequence container requirements
15714 a sequence container is one that satisfies some of the sequence
15715 container requirements. Any operation that the container supports is
15716 specified by one or more sequence container requirements, unless that
15717 operation is specifically singled out and defined alongside the
15718 description of the container itself.
15722 Move to Tentatively NAD.
15727 2009-07-15 Loïc Joly adds:
15733 The section 23.2.3 [sequence.reqmts]/1 states that array is a sequence. 23.2.3 [sequence.reqmts]/3
15734 introduces table 83, named Sequence container requirements. This seems
15735 to me to be defining the requirements for all sequences. However, array
15736 does not follow all of this requirements (this can be read in the array
15737 specific section, for the standard is currently inconsistent).
15741 Proposed resolution 1 (minimal change):
15745 Say that array is a container, that in addition follows only some of the
15746 sequence requirements, as described in the array section:
15750 The library provides <del>five</del> <ins>three</ins> basic kinds of sequence containers: <del><tt>array</tt></del>,
15752 <del><tt>forward_list</tt></del>, <tt>list</tt>, and <tt>deque</tt>. <ins>In addition, <tt>array</tt>
15753 and <tt>forward_list</tt> follows some of the requirements
15754 of sequences, as described in their respective sections.</ins>
15760 Proposed resolution 2 (most descriptive description, no full wording provided):
15763 Introduce the notion of a Fixed Size Sequence, with it requirement table
15764 that would be a subset of the current Sequence container. array would be
15765 the only Fixed Size Sequence (but dynarray is in the queue for TR2).
15766 Sequence requirements would now be requirements in addition to Fixed
15767 Size Sequence requirements (it is currently in addition to container).
15777 Move to NAD Editorial
15786 This will require a lot of reorganization. Editor doesn't think this is really
15787 an issue, since the description of array can be considered as overriding
15788 what's specified about sequences. Move to NAD.
15793 <p><b>Proposed resolution:</b></p>
15802 <h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
15803 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
15804 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
15805 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
15806 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
15807 <p><b>Discussion:</b></p>
15810 The <i>Remark</i> clauses newly introduced into the Working Paper
15811 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
15812 are not mentioned in 17.5.1.4 [structure.specifications] where we list the
15813 meaning of <i>Effects</i>, <i>Requires</i>, and other clauses (with
15814 the exception of <i>Notes</i> which are documented as informative in
15815 17.5.1.2 [structure.summary], p2, and which they replace in many cases).
15820 Propose add a bullet for <i>Remarks</i> along with a brief description.
15824 Batavia: Alan and Pete to work.
15829 Bellevue: Already resolved in current working paper.
15834 <p><b>Proposed resolution:</b></p>
15843 <h3><a name="627"></a>627. Low memory and exceptions</h3>
15844 <p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15845 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-01-23 <b>Last modified:</b> 2010-10-29</p>
15846 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
15847 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15848 <p><b>Discussion:</b></p>
15850 I recognize the need for nothrow guarantees in the exception reporting
15851 mechanism, but I strongly believe that implementors also need an escape hatch
15852 when memory gets really low. (Like, there's not enough heap to construct and
15853 copy exception objects, or not enough stack to process the throw.) I'd like to
15854 think we can put this escape hatch in 18.6.1.1 [new.delete.single],
15855 <tt>operator new</tt>, but I'm not sure how to do it. We need more than a
15856 footnote, but the wording has to be a bit vague. The idea is that if
15857 <tt>new</tt> can't allocate something sufficiently small, it has the right to
15858 <tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
15862 Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within
15863 its resource limits", so no further escape hatch is necessary.
15868 <p><b>Proposed resolution:</b></p>
15877 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
15878 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15879 <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31 <b>Last modified:</b> 2010-10-29</p>
15880 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
15881 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15882 <p><b>Discussion:</b></p>
15884 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
15885 some functions. In particular, it says that:
15889 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
15890 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
15891 iterator arguments, it should work correctly in the construct <tt>if
15892 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
15893 <tt>BinaryPredicate</tt> always takes the first iterator type as its
15894 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
15895 part of the signature, it should work correctly in the context of <tt>if
15896 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
15900 In the description of <tt>upper_bound</tt> (25.4.3.2 [upper.bound]/2), however, the use is described as
15901 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
15902 element of the sequence (a result of dereferencing
15903 <tt>*<i>first</i></tt>).
15907 In the description of <tt>lexicographical_compare</tt>, we have both
15908 "<tt>*<i>first1</i> < *<i>first2</i></tt>" and "<tt>*<i>first2</i>
15909 < *<i>first1</i></tt>" (which presumably implies "<tt>comp(
15910 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
15911 *<i>first1</i> )</tt>".
15915 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
15916 relationship, with the semantics of "less than". Depending on the
15917 function, it may be used to determine equality, or any of the inequality
15918 relationships; doing this requires being able to use it with either
15919 parameter first. I would thus suggest that the requirement be:
15923 Alternatively, one could specify an order for each function. IMHO, this
15924 would be more work for the committee, more work for the implementors,
15925 and of no real advantage for the user: some functions, such as
15926 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
15927 functions, and it seems like a much easier rule to teach that both
15928 functions are always required, rather than to have a complicated list of
15929 when you only need one, and which one.
15933 Toronto: Moved to Open. ConceptGCC seems to get <tt>lower_bound</tt>
15934 and <tt>upper_bound</tt> to work withoutt these changes.
15939 2009-07-28 Reopened by Alisdair. No longer solved by concepts.
15944 2009-10 Santa Cruz:
15949 Move to Review. The small problem with the "iterator type"
15950 will be fixed. The cited functions (<tt>lower_bound</tt>, <tt>uppwer_bound</tt>,
15951 <tt>equal_range</tt>) don't actually use <tt>BinaryPredicate</tt> , and where it is used,
15952 it is consistent with [algorithm]/8, so the main complaint of the issue
15957 2010-01-16 Beman clarified wording.
15962 2010-01-31: Moved to Tentatively NAD after 5 positive votes on c++std-lib.
15963 Rationale added below.
15969 <p><b>Rationale:</b></p>
15971 post San Francisco:
15978 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2759.pdf">N2759</a>.
15983 2010-01-31: The draft standard is well specified as is, and this specification
15984 is desired. Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a> solve the remaining
15985 unclearness regarding the meaning of BinaryPredicate.
15990 <p><b>Proposed resolution:</b></p>
15991 <p><i>Change 25 [algorithms] paragraph 8 as indicated:</i></p>
15996 8 The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a
15997 function object that when applied to the result of dereferencing two
15998 corresponding iterators or to dereferencing an iterator and type <tt>T</tt> when
15999 <tt>T</tt> is part of the signature returns a value testable as true. <ins>
16000 <tt>BinaryPredicate</tt> always takes the first iterator <tt>value_type</tt> as
16001 one of its arguments; which argument is unspecified.</ins> <del>In other words,
16002 if</del> <ins> If</ins> an algorithm takes <tt>BinaryPredicate binary_pred</tt>
16003 as its argument and <tt>first1</tt> and <tt>first2</tt> as its iterator
16004 arguments, it should work correctly <ins>both</ins> in the construct <tt>if
16005 (binary_pred(*first1, *first2)){...}</tt> <ins>and <tt>if (binary_pred (*first2,
16006 *first1)){...}</tt></ins>. <del><tt>BinaryPredicate</tt> always takes the first
16007 iterator type as its first argument, that is, in</del> <ins>In</ins> those cases
16008 when <tt>T value</tt> is part of the signature, it should work correctly in the
16009 context of <tt> if (binary_pred(*first1, value)){...}</tt> <ins>and of <tt>if
16010 (binary_pred (value, *first1)){...}</tt></ins>. <del> <tt>binary_pred</tt> shall
16011 not apply any non-constant function through the dereferenced iterators.</del>
16012 <ins>[<i>Note:</i> if the two types are not identical, and neither is
16013 convertable to the other, this may require that the <tt>BinaryPredicate</tt> be
16014 a functional object with two overloaded <tt>operator()()</tt> functions.
16015 \97 <i>end note</i>]</ins>
16026 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
16027 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16028 <b>Submitter:</b> Lionel B <b>Opened:</b> 2007-02-01 <b>Last modified:</b> 2010-10-29</p>
16029 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
16030 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16031 <p><b>Discussion:</b></p>
16033 A recent news group discussion:
16037 Anyone know if the Standard has anything to say about the time complexity
16038 of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily
16039 during an algorithm and was thus wondering whether I'd be better off
16040 tracking the size "manually" or whether that'd be pointless.
16043 That would be pointless. size() is O(1).
16046 Nit: the standard says "should" have constant time. Implementations may take
16047 license to do worse. I know that some do this for <tt>std::list<></tt> as a part of
16048 some trade-off with other operation.
16052 I was aware of that, hence my reluctance to use size() for std::set.
16055 However, this reason would not apply to <tt>std::set<></tt> as far as I can see.
16058 Ok, I guess the only option is to try it and see...
16063 If I have any recommendation to the C++ Standards Committee it is that
16064 implementations must (not "should"!) document clearly[1], where known, the
16065 time complexity of *all* container access operations.
16068 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
16069 for std::set is not documented... but if it is it's certainly well hidden
16074 Kona (2007): This issue affects all the containers. We'd love to see a
16075 paper dealing with the broad issue. We think that the complexity of the
16076 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
16077 O(1). Alan has volunteered to provide wording.
16087 Mandating O(1) size will not fly, too many implementations would be
16088 invalidated. Alan to provide wording that toughens wording, but that
16089 does not absolutely mandate O(1).
16097 We observed that the wording "should" (in note a) has no effect.
16098 Howard prefers that O(1) size be mandated.
16099 It is not clear that this issue can be resolved to everyone's satisfaction,
16100 but Alan will provide wording nonetheless.
16109 Fixed by paper N2923.
16114 <p><b>Proposed resolution:</b></p>
16123 <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
16124 <p><b>Section:</b> 20.8.14.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16125 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-03 <b>Last modified:</b> 2010-10-29</p>
16126 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16127 <p><b>Discussion:</b></p>
16129 20.8.14.2.5 [func.wrap.func.targ], p4 says:
16132 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
16133 function target; otherwise a null pointer.
16138 There exists neither a type, a typedef <tt>type</tt>, nor member
16139 function <tt>type()</tt> in class template function nor in the global or
16140 <tt>std</tt> namespace.
16143 Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
16144 this description would lead to false results, if <tt>T = <i>cv</i>
16145 void</tt> due to returns clause 20.8.14.2.5 [func.wrap.func.targ], p1.
16151 <p><b>Proposed resolution:</b></p>
16153 Change 20.8.14.2.5 [func.wrap.func.targ], p4:
16157 <i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&& typeid(T) !=
16158 typeid(void)</ins></tt>, a pointer to the stored function target;
16159 otherwise a null pointer.
16163 Pete: Agreed. It's editorial, so I'll fix it.
16173 <h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
16174 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16175 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-11 <b>Last modified:</b> 2010-10-29</p>
16176 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
16177 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16178 <p><b>Discussion:</b></p>
16180 The signature of the const operator[] has been changed to return a const
16184 The description in paragraph 1 still says that the operator returns by
16188 Pete recommends editorial fix.
16193 <p><b>Proposed resolution:</b></p>
16202 <h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
16203 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16204 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-13 <b>Last modified:</b> 2010-10-29</p>
16205 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
16206 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16207 <p><b>Discussion:</b></p>
16209 26.8 [c.math], paragraph 10 has long lists of added signatures for float and long double
16210 functions. All the signatures have float/long double return values, which is
16211 inconsistent with some of the double functions they are supposed to
16216 <p><b>Proposed resolution:</b></p>
16218 Change 26.8 [c.math], paragraph 10,
16221 <blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
16222 <del>float</del> <ins>long</ins> lrint(float);
16223 <del>float</del> <ins>long</ins> lround(float);
16224 <del>float</del> <ins>long long</ins> llrint(float);
16225 <del>float</del> <ins>long long</ins> llround(float);
16227 <del>long double</del> <ins>int</ins> ilogb(long double);
16228 <del>long double</del> <ins>long</ins> lrint(long double);
16229 <del>long double</del> <ins>long</ins> lround(long double);
16230 <del>long double</del> <ins>long long</ins> llrint(long double);
16231 <del>long double</del> <ins>long long</ins> llround(long double);
16232 </pre></blockquote>
16239 <h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
16240 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors], 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16241 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2010-10-29</p>
16242 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
16243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16244 <p><b>Discussion:</b></p>
16246 There already exist two active DR's for the wording of 27.7.1.2.3 [istream::extractors]/13
16247 from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
16251 Even with these proposed corrections, already maintained in N2134,
16252 I have the feeling, that the current wording does still not properly
16253 handle the "exceptional" situation. The combination of para 14
16257 "[..] Characters are extracted and inserted until
16258 any of the following occurs:
16264 - an exception occurs (in which case the exception is caught)."
16272 "If the function inserts no characters, it calls setstate(failbit),
16274 may throw ios_base::failure (27.4.4.3). If it inserted no characters
16275 because it caught an exception thrown while extracting characters
16276 from *this and failbit is on in exceptions() (27.4.4.3), then the
16278 exception is rethrown."
16282 both in N2134 seems to imply that any exception, which occurs
16283 *after* at least one character has been inserted is caught and lost
16285 ever. It seems that even if failbit is on in exceptions() rethrow is
16287 allowed due to the wording "If it inserted no characters because it
16288 caught an exception thrown while extracting".
16292 Is this behaviour by design?
16296 I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
16298 N2134) does not demonstrate such an exception-loss-behaviour.
16299 On the other side, I wonder concerning several subtle differences
16300 compared to input::
16303 1) Paragraph 8 says at its end:
16307 "- an exception occurs while getting a character from sb."
16311 Note that there is nothing mentioned which would imply that such
16312 an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14.
16316 2) Paragraph 9 says:
16320 "If the function inserts no characters, it calls setstate(failbit)
16322 may throw ios_base::failure (27.4.4.3)). If an exception was thrown
16323 while extracting a character, the function sets failbit in error
16325 and if failbit is on in exceptions() the caught exception is
16330 The sentence starting with "If an exception was thrown" seems to
16331 imply that such an exception *should* be caught before.
16335 <p><b>Proposed resolution:</b></p>
16337 (a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
16341 If the function inserts no characters, it calls
16342 <tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
16343 (27.4.4.3). If <del>it inserted no characters because it caught an
16344 exception thrown while extracting characters from <tt>*this</tt></del>
16345 <ins>an exception was thrown while extracting a character from
16346 <tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
16347 and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
16348 caught exception is rethrown.
16352 (b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
16357 Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
16358 Characters are read from <tt>sb</tt> and inserted until any of the
16362 <li>end-of-file occurs on the input sequence;</li>
16363 <li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
16364 <li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
16365 case the exception is caught)</ins>.</li>
16371 <p><b>Rationale:</b></p>
16372 This extractor is described as a formatted input function so the
16373 exception behavior is already specified. There is additional behavior
16374 described in this section that applies to the case in which failbit is
16375 set. This doesn't contradict the usual exception behavior for formatted
16376 input functions because that applies to the case in which badbit is set.
16383 <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
16384 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16385 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-18 <b>Last modified:</b> 2010-10-29</p>
16386 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
16387 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16388 <p><b>Discussion:</b></p>
16390 The function <tt>f</tt> in para 4 (27.7.4 [ext.manip]) references an unknown <tt>strm</tt>
16391 in the following line:
16394 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
16395 </pre></blockquote>
16398 <p><b>Proposed resolution:</b></p>
16400 Change 27.7.4 [ext.manip], p4:
16403 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
16404 </pre></blockquote>
16417 <h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
16418 <p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16419 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2010-10-29</p>
16420 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
16421 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16422 <p><b>Discussion:</b></p>
16424 The standard wording of N2134 has extended the 14882:2003(E)
16425 wording for the ifstream/ofstream/fstream open function to fix
16426 a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
16430 Now it's properly written as
16434 "If that function does not return a null pointer calls clear(),
16436 calls setstate(failbit)[..]"
16440 instead of the previous
16444 "If that function returns a null pointer, calls setstate(failbit)[..]
16448 While the old footnotes saying
16452 "A successful open does not change the error state."
16456 where correct and important, they are invalid now for ifstream and
16457 ofstream (because clear *does* indeed modify the error state) and
16458 should be removed (Interestingly fstream itself never had these,
16460 they where needed for that time).
16464 <p><b>Proposed resolution:</b></p>
16466 In 27.9.1.9 [ifstream.members], remove footnote:
16470 <del><sup>334)</sup> A successful open does not change the error state.</del>
16474 In 27.9.1.13 [ofstream.members], remove footnote:
16478 <del><sup>335)</sup> A successful open does not change the error state.</del>
16487 <h3><a name="644"></a>644. Possible typos in 'function' description</h3>
16488 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16489 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-25 <b>Last modified:</b> 2010-10-29</p>
16490 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
16491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16492 <p><b>Discussion:</b></p>
16494 20.8.14.2 [func.wrap.func]
16497 The note in paragraph 2 refers to 'undefined void operators', while the
16498 section declares a pair of operators returning bool.
16502 Post-Sophia Antipolis:
16507 Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were
16508 changed from private to deleted. The two issues stepped on each other. What do we want the return
16509 type of these deleted functions to be?
16513 2009-05-02 Daniel adds:
16519 I suggest harmonizing this issue with similar classes. E.g. in
16520 20.9.10.3 [util.smartptr.weak] <tt>bool</tt> return values for
16522 <blockquote><pre>template <class Y> bool operator<(weak_ptr<Y> const&) const = delete;
16523 template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete;
16524 template <class Y> bool operator>(weak_ptr<Y> const&) const = delete;
16525 template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete;
16526 </pre></blockquote>
16529 are used and basically all <em>newer</em> provided deleted copy assignment operators
16530 of type <tt>X</tt> use the canonical return type <tt>X&</tt> instead of <tt>void</tt>. Since the note
16531 mentioned in the issue description has now already been changed to
16534 deleted overloads close possible hole in the type system
16537 it seems to be of even lesser need to perform the change. Therefore
16538 I recommend declaring the issue as NAD.
16548 We agree with Daniel's recommendation.
16556 <p><b>Proposed resolution:</b></p>
16558 Change 20.8.14.2 [func.wrap.func]
16561 <blockquote><pre>...
16563 // 20.8.14.2 [func.wrap.func], undefined operators:
16564 template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
16565 template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
16567 </pre></blockquote>
16570 Change 20.8.14.2 [func.wrap.func]
16573 <blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
16574 template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
16575 </pre></blockquote>
16582 <h3><a name="645"></a>645. Missing members in match_results</h3>
16583 <p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16584 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2010-10-29</p>
16585 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
16586 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16587 <p><b>Discussion:</b></p>
16589 According to the description given in 28.10 [re.results]/2 the class template
16590 match_results "shall satisfy the requirements of a Sequence, [..],
16591 except that only operations defined for const-qualified Sequences
16593 Comparing the provided operations from 28.10 [re.results]/3 with the
16594 sequence/container tables 80 and 81 one recognizes the following
16595 missing operations:
16602 <blockquote><pre>const_iterator rbegin() const;
16603 const_iterator rend() const;
16604 </pre></blockquote>
16607 should exists because 23.1/10 demands these for containers
16608 (all sequences are containers) which support bidirectional
16609 iterators. Aren't these supported by match_result? This is not
16610 explicitely expressed, but it's somewhat implied by two arguments:
16613 (a) Several typedefs delegate to
16614 <tt>iterator_traits<BidirectionalIterator></tt>.
16617 (b) The existence of <tt>const_reference operator[](size_type n) const</tt>
16618 implies even random-access iteration.
16619 I also suggest, that <tt>match_result</tt> should explicitly mention,
16620 which minimum iterator category is supported and if this does
16621 not include random-access the existence of <tt>operator[]</tt> is
16622 somewhat questionable.
16625 2) The new "convenience" members
16627 <blockquote><pre>const_iterator cbegin() const;
16628 const_iterator cend() const;
16629 const_iterator crbegin() const;
16630 const_iterator crend() const;
16631 </pre></blockquote>
16633 should be added according to tables 80/81.
16637 <p><b>Proposed resolution:</b></p>
16639 Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
16643 <blockquote><pre>const_iterator cbegin() const;
16644 const_iterator cend() const;
16645 </pre></blockquote>
16648 In section 28.10.4 [re.results.acc] change:
16652 <pre>const_iterator begin() const;
16653 <ins>const_iterator cbegin() const;</ins>
16657 -7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
16661 <pre>const_iterator end() const;
16662 <ins>const_iterator cend() const;</ins>
16666 -8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
16674 Kona (2007): Voted to adopt proposed wording in
16675 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
16676 except removing the entry in the table container requirements. Moved to Review.
16681 Bellevue: Proposed wording now in the WP.
16689 <h3><a name="647"></a>647. Inconsistent regex_search params</h3>
16690 <p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16691 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2010-10-29</p>
16692 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16693 <p><b>Discussion:</b></p>
16695 28.11.3 [re.alg.search]/5 declares
16698 <blockquote><pre>template <class iterator, class charT, class traits>
16699 bool regex_search(iterator first, iterator last,
16700 const basic_regex<charT, traits>& e,
16701 regex_constants::match_flag_type flags =
16702 regex_constants::match_default);
16703 </pre></blockquote>
16706 where it's not explained, which iterator category
16707 the parameter iterator belongs to. This is inconsistent
16708 to the preceding declaration in the synopsis section
16709 28.4 [re.syn], which says:
16712 <blockquote><pre>template <class BidirectionalIterator, class charT, class traits>
16713 bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
16714 const basic_regex<charT, traits>& e,
16715 regex_constants::match_flag_type flags =
16716 regex_constants::match_default);
16717 </pre></blockquote>
16720 <p><b>Proposed resolution:</b></p>
16722 In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
16723 "BidirectionalIterator"
16726 <blockquote><pre>template <class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits>
16727 bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
16728 const basic_regex<charT, traits>& e,
16729 regex_constants::match_flag_type flags =
16730 regex_constants::match_default);
16733 -6- <i>Effects:</i> Behaves "as if" by constructing an object what of
16734 type <tt>match_results<<del>iterator</del>
16735 <ins>BidirectionalIterator</ins>></tt> and then returning the result
16736 of <tt>regex_search(first, last, what, e, flags)</tt>.
16741 <p><b>Rationale:</b></p>
16742 Applied to working paper while issue was still in New status.
16749 <h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
16750 <p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16751 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-03 <b>Last modified:</b> 2010-10-29</p>
16752 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16753 <p><b>Discussion:</b></p>
16755 In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
16760 <i>Effects:</i> Initializes begin and end to point to the beginning and the
16761 end of the target sequence, sets pregex to &re, sets flags to f,[..]
16765 There are two issues with this description:
16770 The meaning of very first part of this quote is unclear, because
16771 there is no target sequence provided, instead there are given two
16772 parameters a and b, both of type BidirectionalIterator. The mentioned
16773 part does not explain what a and b represent.
16776 There does not exist any parameter f, but instead a parameter
16777 m in the constructor declaration, so this is actually an editorial
16783 <p><b>Proposed resolution:</b></p>
16785 In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
16789 <i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
16790 the beginning and the end of the target sequence <ins>designated by the
16791 iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
16792 <tt>&re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
16793 <ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
16794 *pregex, flags)</tt>. If this call returns <tt>false</tt> the
16795 constructor sets <tt>*this</tt> to the end-of-sequence iterator.
16803 <h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
16804 <p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16805 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-03 <b>Last modified:</b> 2010-10-29</p>
16806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
16807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16808 <p><b>Discussion:</b></p>
16810 In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
16811 and the following text shows some obvious typos:
16814 1) The third constructor form is written as
16816 <blockquote><pre>template <std::size_t N>
16817 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
16818 const regex_type& re,
16819 const int (&submatches)[R],
16820 regex_constants::match_flag_type m =
16821 regex_constants::match_default);
16822 </pre></blockquote>
16825 where the dimensions of submatches are specified by an
16826 unknown value R, which should be N.
16829 2) Paragraph 2 of the same section says in its last sentence:
16833 The third constructor initializes the member <tt>subs</tt> to hold a
16834 copy of the sequence of integer values pointed to by the iterator range
16835 <tt>[&submatches, &submatches + R)</tt>.
16839 where again R must be replaced by N.
16843 3) Paragraph 3 of the same section says in its first sentence:
16847 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
16848 <tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
16852 where a non-existing parameter "f" is mentioned, which must be
16854 by the parameter "m".
16858 <p><b>Proposed resolution:</b></p>
16860 Change 28.12.2.1 [re.tokiter.cnstr]/1:
16862 <blockquote><pre>template <std::size_t N>
16863 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
16864 const regex_type& re,
16865 const int (&submatches)[<del>R</del> <ins>N</ins>],
16866 regex_constants::match_flag_type m =
16867 regex_constants::match_default);
16868 </pre></blockquote>
16871 Change 28.12.2.1 [re.tokiter.cnstr]/2:
16875 <i>Effects:</i> The first constructor initializes the member
16876 <tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
16877 constructor initializes the member <tt>subs</tt> to hold a copy of the
16878 argument <tt>submatches</tt>. The third constructor initializes the
16879 member <tt>subs</tt> to hold a copy of the sequence of integer values
16880 pointed to by the iterator range <tt>[&submatches, &submatches +
16881 <del>R</del> <ins>N</ins>)</tt>.
16885 Change 28.12.2.1 [re.tokiter.cnstr]/3:
16889 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
16890 <tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
16891 <ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
16892 iterator the constructor sets <tt>result</tt> to the address of the
16893 current match. Otherwise if any of the values stored in <tt>subs</tt> is
16894 equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
16895 iterator that points to the range <tt>[a, b)</tt>, otherwise the
16896 constructor sets <tt>*this</tt> to an end-of-sequence iterator.
16905 <h3><a name="653"></a>653. Library reserved names</h3>
16906 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16907 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
16908 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
16909 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16910 <p><b>Discussion:</b></p>
16915 1.2 [intro.refs] Normative references
16919 The following standards contain provisions which, through reference in
16920 this text, constitute provisions of this Interna- tional Standard. At
16921 the time of publication, the editions indicated were valid. All
16922 standards are subject to revision, and parties to agreements based on
16923 this International Standard are encouraged to investigate the
16924 possibility of applying the most recent editions of the standards
16925 indicated below. Members of IEC and ISO maintain registers of currently
16926 valid International Standards.
16930 <li>Ecma International, ECMAScript Language Specification, Standard
16931 Ecma-262, third edition, 1999.</li>
16932 <li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
16933 <li>ISO/IEC 9899:1990, Programming languages - C</li>
16934 <li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
16936 <li>ISO/IEC 9899:1999, Programming languages - C</li>
16937 <li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
16938 <li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
16939 <li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
16940 Interface (POSIX)</li>
16941 <li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
16942 Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
16948 I'm not sure how many of those reserve naming patterns that might affect
16949 us, but I am equally sure I don't own a copy of any of these to check!
16952 The point is to list the reserved naming patterns, rather than the
16953 individual names themselves - although we may want to list C keywords
16954 that are valid identifiers in C++ but likely to cause trouble in shared
16955 headers (e.g. restrict)
16959 Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one.
16964 Post-Kona: Alisdair request Open. A good example of the problem was a
16965 discussion of the system error proposal, where it was pointed out an all-caps
16966 identifier starting with a capital E conflicted with reserved macro names for
16967 both Posix and C. I had absolutely no idea of this rule, and suspect I was
16968 not the only one in the room.<br>
16970 Resolution will require someone with access to all the listed documents to
16971 research their respective name reservation rules, or people with access to
16972 specific documents add their rules to this issue until the list is complete.
16977 Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
16978 Suggest a formal paper rather than a defect report is the correct way to proceed.
16984 <p><b>Proposed resolution:</b></p>
16991 <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
16992 <p><b>Section:</b> 26.5.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
16993 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
16994 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
16995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
16996 <p><b>Discussion:</b></p>
16998 26.5.2 [rand.synopsis] the header <tt><random></tt> synopsis
16999 contains an unreasonable closing curly brace inside the
17000 <tt>subtract_with_carry_engine</tt> declaration.
17004 <p><b>Proposed resolution:</b></p>
17006 Change the current declaration in 26.5.2 [rand.synopsis]
17009 <blockquote><pre>template <class UIntType, size_t w<del>}</del>, size_t s, size_t r>
17010 class subtract_with_carry_engine;
17011 </pre></blockquote>
17015 Pete: Recommends editorial.
17023 <h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
17024 <p><b>Section:</b> 17.6.2.2 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17025 <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2007-03-14 <b>Last modified:</b> 2010-10-29</p>
17026 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17027 <p><b>Discussion:</b></p>
17029 17.6.2.2 [using.headers] states:
17033 A translation unit shall include a header only outside of any
17034 external declaration or definition, [...]
17038 I see three problems with this requirement:
17042 <li><p>The C++ standard doesn't define what an "external declaration" or
17043 an "external definition" are (incidentally the C99 standard does, and
17044 has a sentence very similar to the above regarding header inclusion).
17046 I think the intent is that the #include directive shall lexically
17047 appear outside *any* declaration; instead, when the issue was pointed
17048 out on comp.std.c++ at least one poster interpreted "external
17049 declaration" as "declaration of an identifier with external linkage".
17050 If this were the correct interpretation, then the two inclusions below
17053 <blockquote><pre> // at global scope
17056 # include <cstddef>
17061 # include <stddef.h>
17063 </pre></blockquote>
17065 (note that while the first example is unlikely to compile correctly,
17066 the second one may well do)
17069 <li><p>as the sentence stands, violations will require a diagnostic; is
17070 this the intent? It was pointed out on comp.std.c++ (by several
17071 posters) that at least one way to ensure a diagnostic exists:
17074 [If there is an actual file for each header,] one simple way
17075 to implement this would be to insert a reserved identifier
17076 such as __begin_header at the start of each standard header.
17077 This reserved identifier would be ignored for all other
17078 purposes, except that, at the appropriate point in phase 7, if
17079 it is found inside an external definition, a diagnostic is
17080 generated. There's many other similar ways to achieve the same
17083 <p> --James Kuyper, on comp.std.c++
17084 </p></blockquote></li>
17086 <li><p>is the term "header" meant to be limited to standard headers?
17087 Clause 17 is all about the library, but still the general question is
17088 interesting and affects one of the points in the explicit namespaces
17089 proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
17092 Those seeking to conveniently enable argument-dependent
17093 lookups for all operators within an explicit namespace
17094 could easily create a header file that does so:
17095 </p><pre> namespace mymath::
17097 #include "using_ops.hpp"
17099 </pre></blockquote>
17104 <p><b>Proposed resolution:</b></p>
17109 <p><b>Rationale:</b></p>
17110 We believe that the existing language does not cause any real confusion
17111 and any new formulation of the rules that we could come up with are
17112 unlikely to be better than what's already in the standard.
17119 <h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3>
17120 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17121 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2007-04-05 <b>Last modified:</b> 2010-10-29</p>
17122 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
17123 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17124 <p><b>Discussion:</b></p>
17126 From Section 22.4.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
17127 that the value read from a stream must be stored
17128 even if the placement of thousands separators does not conform to the
17129 <code>grouping()</code> specification from the <code>numpunct</code> facet.
17130 Since incorrectly-placed thousands separators are flagged as an extraction
17131 failure (by the means of <code>failbit</code>), we believe it is better not
17132 to store the value. A consistent strategy, in which any kind of extraction
17133 failure leaves the input item intact, is conceptually cleaner, is able to avoid
17134 corner-case traps, and is also more understandable from the programmer's point
17138 Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
17139 by B. Stroustrup (Section D.4.2.3, pg. 897):
17142 <i>"If a value of the desired type could not be read, failbit is set in r.
17143 [...] An input operator will use r to determine how to set the state of its
17144 stream. If no error was encountered, the value read is assigned through v;
17145 otherwise, v is left unchanged."</i>
17148 This statement implies that <code>rdstate()</code> alone is sufficient to
17149 determine whether an extracted value is to be assigned to the input item
17150 <i>val</i> passed to <code>do_get</code>. However, this is in disagreement
17151 with the current C++ Standard. The above-mentioned assumption is true in all
17152 cases, except when there are mismatches in digit grouping. In the latter case,
17153 the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
17154 is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
17155 success of the operation). Is this intentional? The current behavior raises
17156 both consistency and usability concerns.
17159 Although digit grouping is outside the scope of <code>scanf</code> (on which
17160 the virtual methods of <code>num_get</code> are based), handling of grouping
17161 should be consistent with the overall behavior of scanf. The specification of
17162 <code>scanf</code> makes a distinction between input failures and matching
17163 failures, and yet both kinds of failures have no effect on the input items
17164 passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
17165 the category of matching failures, and it would be more consistent, and less
17166 surprising to the user, to leave the input item intact whenever a failure is
17170 The extraction of <code>bool</code> is another example outside the scope of
17171 <code>scanf</code>, and yet consistent, even in the event of a successful
17172 extraction of a <code>long</code> but a failed conversion from
17173 <code>long</code> to <code>bool</code>.
17176 Inconsistency is further aggravated by the fact that, when failbit is set,
17177 subsequent extraction operations are no-ops until <code>failbit</code> is
17178 explicitly cleared. Assuming that there is no explicit handling of
17179 <code>rdstate()</code> (as in <code>cin>>i>>j</code>) it is
17180 counter-intuitive to be able to extract an integer with mismatched digit
17181 grouping, but to be unable to extract another, properly-formatted integer
17182 that immediately follows.
17185 Moreover, setting <code>failbit</code>, and selectively assigning a value to
17186 the input item, raises usability problems. Either the strategy of
17187 <code>scanf</code> (when there is no extracted value in case of failure), or
17188 the strategy of the <code>strtol</code> family (when there is always an
17189 extracted value, and there are well-defined defaults in case of a failure) are
17190 easy to understand and easy to use. On the other hand, if <code>failbit</code>
17191 alone cannot consistently make a difference between a failed extraction, and a
17192 successful but not-quite-correct extraction whose output happens to be the same
17193 as the previous value, the programmer must resort to implementation tricks.
17194 Consider the following example:
17196 <pre> int i = old_i;
17199 // can the value of i be trusted?
17200 // what does it mean if i == old_i?
17204 Last but not least, the current behvaior is not only confusing to the casual
17205 reader, but it has also been confusing to some book authors. Besides
17206 Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
17207 Langer and Kreft) are describing the same mistaken assumption. Although books
17208 are not to be used instead of the standard reference, the readers of these
17209 books, as well as the people who are generally familiar to <code>scanf</code>,
17210 are even more likely to misinterpret the standard, and expect the input items
17211 to remain intact when a failure occurs.
17215 <p><b>Proposed resolution:</b></p>
17218 Change 22.4.2.1.2 [facet.num.get.virtuals]:
17223 <b>Stage 3:</b> The result of stage 2 processing can be one of
17226 <li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
17228 <li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
17231 <ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet<numpunct<charT> >(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
17236 <p><b>Rationale:</b></p>
17237 post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of
17238 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
17239 makes this resolution obsolete.
17246 <h3><a name="663"></a>663. Complexity Requirements</h3>
17247 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17248 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
17249 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
17250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17251 <p><b>Discussion:</b></p>
17253 17.5.1.4 [structure.specifications] para 5 says
17257 -5- Complexity requirements specified in the library
17258 clauses are upper bounds, and implementations that provide better
17259 complexity guarantees satisfy the requirements.
17264 objection has been raised:
17268 The library clauses suggest general
17269 guidelines regarding complexity, but we have been unable to discover
17270 any absolute hard-and-fast formulae for these requirements. Unless
17271 or until the Library group standardizes specific hard-and-fast
17272 formulae, we regard all the complexity requirements as subject to a
17273 "fudge factor" without any intrinsic upper bound.
17282 <p><b>Proposed resolution:</b></p>
17287 <p><b>Rationale:</b></p>
17288 Kona (2007): No specific instances of underspecification have been
17289 identified, and big-O notation always involves constant factors.
17296 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
17297 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17298 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
17299 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
17300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17301 <p><b>Discussion:</b></p>
17303 22.4.6.1.2 [locale.money.get.virtuals], para 1 says:
17307 The result is returned as an integral value
17308 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
17309 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
17310 from '0' through '9', inclusive) stored in <tt>digits</tt>.
17315 objection has been raised:
17319 Some implementations interpret this to mean that a facet derived from
17320 <tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
17321 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
17322 <tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
17323 implementations have assumed that one or more places in the standard permit the
17324 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
17325 both interpretations permissible, or only one?
17329 [Plum ref _222612Y14]
17333 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
17334 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
17338 Kona (2007): Bill and Dietmar to provide proposed wording.
17343 post Bellevue: Bill adds:
17348 The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
17349 The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
17350 which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
17351 the widened characters are not relevant to the parsing of the subject string.
17359 We agree with Bill's comment above,
17360 in line with the first of the interpretations offered in the issue.
17365 <p><b>Proposed resolution:</b></p>
17374 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
17375 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17376 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
17377 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
17378 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17379 <p><b>Discussion:</b></p>
17381 22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
17385 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
17386 optional, and if no sign is detected, the result is given the sign
17387 that corresponds to the source of the empty string.
17391 The following objection has been raised:
17395 A <tt>negative_sign</tt> of "" means "there is no
17396 way to write a negative sign" not "any null sequence is a negative
17397 sign, so it's always there when you look for it".
17401 [Plum ref _222612Y32]
17405 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
17410 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.
17414 2009-05-17 Howard adds:
17420 I disagree that a <tt>negative_sign</tt> of "" means "there is no way to
17421 write a negative sign". The meaning requires the sentences of 22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above to be
17422 taken into account:
17426 -3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
17427 optional, and if no sign is detected, the result is given the sign that
17428 corresponds to the source of the empty string. Otherwise, the character
17429 in the indicated position must match the first character of <tt>pos</tt>
17430 or <tt>neg</tt>, and the result is given the corresponding sign. If the
17431 first character of <tt>pos</tt> is equal to the first character of
17432 <tt>neg</tt>, or if both strings are empty, the result is given a
17437 So a <tt>negative_sign</tt> of "" means "there is no way to write a
17438 negative sign" only when <tt>positive_sign</tt> is also "". However
17439 when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() >
17440 0</tt>, then one writes a negative value by not writing the
17441 <tt>postive_sign</tt> in the position indicated by
17442 <tt>money_base::sign</tt>.
17446 <blockquote><pre>pattern = {symbol, sign, value, none}
17447 positive_sign = "+"
17449 $123 // a negative value, using optional sign
17450 $+123 // a positive value
17451 $-123 // a parse error
17452 </pre></blockquote>
17458 <blockquote><pre>pattern = {symbol, sign, value, none}
17461 $123 // a positive value, no sign possible
17462 $+123 // a parse error
17463 $-123 // a parse error
17464 </pre></blockquote>
17468 And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>):
17471 <blockquote><pre>pattern = {symbol, sign, value, none}
17472 positive_sign = "-"
17473 negative_sign = "-"
17474 $123 // a parse error, sign is mandatory
17475 $+123 // a parse error
17476 $-123 // a positive value
17477 </pre></blockquote>
17481 The text seems both unambiguous and clear to me. I recommend NAD for
17482 both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>. However I would have no
17483 objection to adding examples such as those above.
17493 This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> (q.v.).
17494 Howard has added examples above,
17495 and recommends either NAD or a resolution that adds his (or similar) examples
17496 to the Working Paper.
17499 Alan would like to rewrite paragraph 3.
17502 We recommend moving to NAD.
17503 Anyone who feels strongly about adding the examples
17504 is invited to submit corresponding wording.
17505 We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> be handled identically.
17510 2009-07-14 Alan reopens with improved wording.
17520 No consensus for closing as NAD. Leave in Review.
17524 2009-10 Santa Cruz:
17529 NAD. Agreed that the original assessment as NAD was correct.
17534 <p><b>Proposed resolution:</b></p>
17536 Change 22.4.6.1.2 [locale.money.get.virtuals] p3:
17540 -3- <del>If the first character (if any) in the string pos returned by
17541 <tt>mp.positive_sign()</tt> or the string <tt>neg</tt> returned by
17542 <tt>mp.negative_sign()</tt> is recognized in the position indicated by
17543 sign in the format pattern, it is consumed and any remaining characters
17544 in the string are required after all the other format components.
17545 [<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
17546 value of "()" and a currency symbol of "L", in "(100 L)" the "L" is
17547 consumed; but if <tt>neg</tt> is "-", the "L" in "-100 L" is not
17548 consumed. -- <i>end example</i>] If <tt>pos</tt> or <tt>neg</tt> is
17549 empty, the sign component is optional, and if no sign is detected, the
17550 result is given the sign that corresponds to the source of the empty
17551 string. Otherwise, the character in the indicated position must match
17552 the first character of <tt>pos</tt> or <tt>neg</tt>, and the result is
17553 given the corresponding sign. If the first character of <tt>pos</tt> is
17554 equal to the first character of <tt>neg</tt>, or if both strings are
17555 empty, the result is given a positive sign.</del>
17557 <ins>The sign pattern strings <tt>pos</tt> and <tt>neg</tt> are returned by
17558 <tt>mp.positive_sign()</tt> and <tt>mp.negative_sign()</tt> respectively. A sign pattern
17559 is matched if its first character is recognized in <tt>s</tt> in the position
17560 indicated by <tt>sign</tt> in the format pattern, or if the pattern is empty and
17561 there is no sign recognized in <tt>s</tt>. A match is required to occur. If both
17562 patterns are matched, the result is given a positive sign, otherwise the
17563 result is given the sign corresponding to the matched pattern.
17564 If the pattern contains more than one character, the characters after the first
17565 must be matched in <tt>s</tt> after all other format components.
17567 characters are matched, <tt>s</tt> is consumed up to and including those characters.
17568 [<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
17569 value of "<tt>()</tt>" and a currency symbol of "<tt>L</tt>", in
17570 "<tt>(100 L)</tt>" the entire string is consumed; but for a <tt>neg</tt>
17571 value of "<tt>-</tt>", in "<tt>-100 L</tt>", the string is consumed
17572 through the second "<tt>0</tt>" (the space and "<tt>L</tt>" are not consumed).
\97 <i>end
17573 example</i>] </ins>
17581 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
17582 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17583 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
17584 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
17585 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17586 <p><b>Discussion:</b></p>
17588 22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
17592 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
17593 or if both strings are empty, the result is given a positive sign.
17597 One interpretation is that an input sequence must match either the
17598 positive pattern or the negative pattern, and then in either event it
17599 is interpreted as positive. The following objections has been raised:
17603 The input can successfully match only a positive sign, so the negative
17604 pattern is an unsuccessful match.
17608 [Plum ref _222612Y34, 222612Y51b]
17612 Bill to provide proposed wording and interpretation of existing wording.
17617 2009-05-17 See Howard's comments in related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.
17627 This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a> (q.v.).
17628 Howard has added examples there,
17629 and recommends either NAD or a resolution that adds his (or similar) examples
17630 to the Working Paper.
17633 We recommend moving to NAD.
17634 Anyone who feels strongly about adding the examples
17635 is invited to submit corresponding wording.
17636 We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a> be handled identically.
17641 <p><b>Proposed resolution:</b></p>
17650 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
17651 <p><b>Section:</b> 22.4.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
17652 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
17653 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
17654 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a></p>
17655 <p><b>Discussion:</b></p>
17657 22.4.6.3 [locale.moneypunct], para 2 says:
17661 The value <tt>space</tt> indicates that at least one space is required at
17666 The following objection has been raised:
17670 Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
17674 [Plum ref _22263Y22]
17678 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
17679 ambiguous, and that we want C++0X to say "space" means 0 or more
17680 whitespace characters on input.
17686 <p><b>Proposed resolution:</b></p>
17693 <h3><a name="683"></a>683. regex_token_iterator summary error</h3>
17694 <p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
17695 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-02 <b>Last modified:</b> 2010-10-29</p>
17696 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
17697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
17698 <p><b>Discussion:</b></p>
17700 28.12.2 [re.tokiter], p3 says:
17704 After it is constructed, the iterator finds and stores a value
17705 <tt>match_results<BidirectionalIterator></tt> position and sets the
17706 internal count <tt>N</tt> to zero.
17716 After it is constructed, the iterator finds and stores a value
17717 <tt><del>match_results</del><ins>regex_iterator</ins><BidirectionalIterator<ins>, charT, traits</ins>></tt>
17718 position and sets the internal count <tt>N</tt> to zero.
17728 Yep, looks like a typo/administrative fix to me.
17733 <p><b>Proposed resolution:</b></p>
17742 <h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
17743 <p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
17744 <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27 <b>Last modified:</b> 2010-10-29</p>
17745 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
17746 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
17747 <p><b>Discussion:</b></p>
17749 In 28.4 [re.syn] of N2284, two template functions
17752 <blockquote><pre>// 28.10, class template match_results:
17753 <<i>snip</i>>
17754 // match_results comparisons
17755 template <class BidirectionalIterator, class Allocator>
17756 bool operator== (const match_results<BidirectionalIterator, Allocator>& m1,
17757 const match_results<BidirectionalIterator, Allocator>& m2);
17758 template <class BidirectionalIterator, class Allocator>
17759 bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1,
17760 const match_results<BidirectionalIterator, Allocator>& m2);
17762 // 28.10.6, match_results swap:
17763 </pre></blockquote>
17766 But the details of these two bool operator functions (i.e., which members of
17767 <tt>match_results</tt> should be used in comparison) are not described in any
17768 following sections.
17777 That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
17778 the two objects refer to the same match - ie if one object was constructed as a
17783 Kona (2007): Bill and Pete to add minor wording to that proposed in
17784 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
17789 <p><b>Proposed resolution:</b></p>
17791 Add a new section after 28.10.7 [re.results.swap], which reads:
17794 28.10.7 match_results non-member functions.
17798 <pre>template<class BidirectionalIterator, class Allocator>
17799 bool operator==(const match_results<BidirectionalIterator, Allocator>& m1,
17800 const match_results<BidirectionalIterator, Allocator>& m2);
17804 <i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
17810 <pre>template<class BidirectionalIterator, class Allocator>
17811 bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1,
17812 const match_results<BidirectionalIterator, Allocator>& m2);
17816 <i>Returns:</i> <tt>!(m1 == m2)</tt>.
17822 <pre>template<class BidirectionalIterator, class Allocator>
17823 void swap(match_results<BidirectionalIterator, Allocator>& m1,
17824 match_results<BidirectionalIterator, Allocator>& m2);
17828 <i>Returns:</i> <tt>m1.swap(m2)</tt>.
17835 Bellevue: Proposed wording now in WP.
17843 <h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
17844 <p><b>Section:</b> 20.9.9.2.4 [unique.ptr.single.observers], 20.9.10.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17845 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-06-14 <b>Last modified:</b> 2010-10-29</p>
17846 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17847 <p><b>Discussion:</b></p>
17849 The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
17850 five places. In three of those places (20.8.14.2.3 [func.wrap.func.cap], function capacity
17851 for example) the returned value is constrained to disallow
17852 unintended conversions to int. The standardese is
17855 The return type shall not be convertible to <tt>int</tt>.
17858 This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
17867 Close as NAD. Accepting paper
17868 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
17869 makes it irrelevant.
17874 <p><b>Proposed resolution:</b></p>
17876 To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
17877 const</tt> of 20.9.9.2.4 [unique.ptr.single.observers] paragraph 11 and 20.9.10.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
17880 The return type shall not be convertible to <tt>int</tt>.
17885 Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
17893 <h3><a name="690"></a>690. abs(long long) should return long long</h3>
17894 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
17895 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-06-10 <b>Last modified:</b> 2010-10-29</p>
17896 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
17897 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
17898 <p><b>Discussion:</b></p>
17900 Quoting the latest draft (n2135), 26.8 [c.math]:
17905 The added signatures are:
17907 <blockquote><pre>long abs(long); // labs()
17908 long abs(long long); // llabs()
17909 </pre></blockquote>
17912 Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
17916 <p><b>Proposed resolution:</b></p>
17918 Change 26.8 [c.math]:
17920 <blockquote><pre><ins>long </ins>long abs(long long); // llabs()
17921 </pre></blockquote>
17924 <p><b>Rationale:</b></p>
17925 Had already been fixed in the WP by the time the LWG reviewed this.
17932 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
17933 <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17934 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2010-10-29</p>
17935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17936 <p><b>Discussion:</b></p>
17938 I see that the definition the associated Laguerre
17939 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
17940 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
17941 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
17942 while the associated Laguerre polynomials are actually valid for real
17943 values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the
17944 definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
17945 must be used, which also holds for integer values of <tt>m</tt>. See
17946 Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
17947 the integer case. In fact fractional values are most commonly used in
17948 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
17949 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
17953 If I am correct, the calculation of the more general case is no
17954 more difficult, and is in fact the function implemented in the GNU
17955 Scientific Library. I would urge you to consider upgrading the
17956 standard, either adding extra functions for real <tt>m</tt> or switching the
17957 current ones to <tt>double</tt>.
17966 We understand the issue, and have opted not to extend as recommended.
17974 <p><b>Proposed resolution:</b></p>
17983 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
17984 <p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17985 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2010-10-29</p>
17986 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17987 <p><b>Discussion:</b></p>
17989 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
17990 <tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p>
17998 The error has been corrected in the pending IS.
18006 <p><b>Proposed resolution:</b></p>
18015 <h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
18016 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18017 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-07-20 <b>Last modified:</b> 2010-10-29</p>
18018 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
18019 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
18020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18021 <p><b>Discussion:</b></p>
18024 From the Toronto Core wiki:
18028 What do you mean by "null pointer constant"? How do you guarantee that
18029 <tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that?
18030 What's the semantics? What about <tt>void *p = 0; exception_ptr() == p</tt>?
18031 Maybe disallow those in the interface, but how do you do that with
18032 portable C++? Could specify just "make it work".
18040 null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
18041 work", can be implemented as assignment operator taking a unique pointer
18042 to member, as in the unspecified bool type idiom.
18052 Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
18055 Even simpler now with nullptr_t.
18058 NAD Rationale : null pointer constant is a perfectly defined term, and
18059 while API is clearly implementable there is no need to spell out
18060 implementation details.
18066 <p><b>Proposed resolution:</b></p>
18075 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
18076 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
18077 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-07-28 <b>Last modified:</b> 2010-10-29</p>
18078 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
18079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
18080 <p><b>Discussion:</b></p>
18082 The POSIX "Extended API Set Part 4,"
18085 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
18088 introduces extensions to the C locale mechanism that
18089 allow multiple concurrent locales to be used in the same application
18090 by introducing a type <tt>locale_t</tt> that is very similar to
18091 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
18094 The global locale (set by setlocale) is now specified to be per-
18095 process. If a thread does not call <tt>uselocale</tt>, the global locale is
18096 in effect for that thread. It can install a per-thread locale by
18097 using <tt>uselocale</tt>.
18100 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
18101 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
18102 locales, with no <tt>std::locale</tt> equivalent.
18105 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
18106 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
18110 Kona (2007): Bill and Nick to provide wording.
18115 San Francisco: Bill and Nick still intend to provide wording, but this
18116 is a part of the task to be addressed by the group that will look into
18117 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>.
18128 It's our intention to stay in sync with WG14. If WG14 makes a decision
18129 that requires a change in WG21 the issue will be reopened.
18132 Move to NAD Future.
18138 <p><b>Proposed resolution:</b></p>
18147 <h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
18148 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
18149 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2010-10-29</p>
18150 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
18151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
18152 <p><b>Discussion:</b></p>
18154 Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
18155 changed to <tt>const T&</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
18156 the section 26.6.2.3 [valarray.access] are now
18158 specified, because many requirements and guarantees should now also
18159 apply to the const overload. Most notably, the address and reference
18160 guarantees should be extended to the const overload case.
18164 <p><b>Proposed resolution:</b></p>
18166 Change 26.6.2.3 [valarray.access]:
18171 -1- <del>When applied to a constant array, the subscript operator returns a
18172 reference to the corresponding element of the array. When applied to a
18173 non-constant array, t</del><ins>T</ins>he subscript operator returns a
18174 reference to the corresponding element of the array.
18178 -3- The expression <tt>&a[i+j] == &a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
18179 and <tt>size_t j</tt> such that <tt>i+j</tt> is less
18180 than the length of the <del>non-constant</del> array <tt>a</tt>.
18184 -4- Likewise, the expression <tt>&a[i] != &b[j]</tt> evaluates
18185 as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
18186 <tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
18187 <tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
18188 than the length of <tt>b</tt>. This property indicates an absence of
18189 aliasing and may be used to advantage by optimizing
18190 compilers.<sup>281)</sup>
18194 -5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
18195 the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime
18196 of that array ends, whichever happens first.
18207 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
18208 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
18209 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-18 <b>Last modified:</b> 2010-10-29</p>
18210 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
18211 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
18212 <p><b>Discussion:</b></p>
18214 Paragraph 21.4 [basic.string]/3 states:
18219 The class template <tt>basic_string</tt> conforms to the requirements for a
18220 Sequence (23.1.1) and for a Reversible Container (23.1).
18225 First of all, 23.2.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
18226 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
18227 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
18228 even close to conform to the current requirements.
18238 <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
18239 <li>with concepts do we need to maintain string as sequence container?</li>
18240 <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
18243 <li>basic_string already has push_back</li>
18244 <li>const_iterator parameters to insert and erase should be added to basic_string</li>
18245 <li>this leaves emplace to handle -- we have the following options:
18247 <li>option 1: add it to string even though it's optional</li>
18248 <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
18249 <li>option 3: say string not sequence (the proposal),</li>
18250 <li>option 4: add an exception to basic string wording.</li>
18254 General consensus is to suggest option 2.
18263 Move to NAD Editorial
18268 <p><b>Proposed resolution:</b></p>
18270 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
18271 not just a <tt>vector</tt>-light for literal types, but something quite
18272 different, a string abstraction in its own right.
18280 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
18281 <p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18282 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2010-10-29</p>
18283 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
18284 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18285 <p><b>Discussion:</b></p>
18287 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
18288 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
18289 be used (because of a protected destructor).
18293 How are we going to explain this code to beginning programmers?
18296 <blockquote><pre>template<class I, class E, class S>
18297 struct codecvt : std::codecvt<I, E, S>
18305 std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
18307 std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
18309 </pre></blockquote>
18317 Bill will propose a resolution.
18327 codecvt isn't intended for beginning programmers. This is a regrettable
18328 consequence of the original design of the facet.
18336 <p><b>Proposed resolution:</b></p>
18345 <h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
18346 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
18347 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2007-09-16 <b>Last modified:</b> 2010-10-29</p>
18348 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
18349 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
18350 <p><b>Discussion:</b></p>
18352 Table 90: (Optional sequence container operations) states the
18353 "assertion note pre/post-condition" of <tt>operator[]</tt> to be
18356 <blockquote><pre>*(a.begin() + n)
18357 </pre></blockquote>
18360 Surely that's meant to be "operational semantics?"
18365 <p><b>Proposed resolution:</b></p>
18368 <caption>Table 90: Optional sequence container operations</caption>
18370 <th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
18381 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
18382 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18383 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2010-10-29</p>
18384 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
18385 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18386 <p><b>Discussion:</b></p>
18388 Two overloads of <tt>regex_replace()</tt> are currently provided:
18391 <blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
18392 class traits, class charT>
18394 regex_replace(OutputIterator out,
18395 BidirectionalIterator first, BidirectionalIterator last,
18396 const basic_regex<charT, traits>& e,
18397 const basic_string<charT>& fmt,
18398 regex_constants::match_flag_type flags =
18399 regex_constants::match_default);
18401 template <class traits, class charT>
18402 basic_string<charT>
18403 regex_replace(const basic_string<charT>& s,
18404 const basic_regex<charT, traits>& e,
18405 const basic_string<charT>& fmt,
18406 regex_constants::match_flag_type flags =
18407 regex_constants::match_default);
18408 </pre></blockquote>
18411 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
18412 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
18414 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
18416 <blockquote><pre>const string s("kitten");
18417 const regex r("en");
18418 cout << regex_replace(s, r, "y") << endl;
18419 </pre></blockquote>
18422 The compiler error message will be something like "could not deduce
18423 template argument for 'const std::basic_string<_Elem> &' from 'const
18428 Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
18429 <tt>const charT *</tt>. In their own code, when they write a function taking
18430 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
18431 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
18432 regex algorithms are templated on <tt>charT</tt>, they can't rely on
18433 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
18434 indicates, template argument deduction fails first).
18438 If a user figures out what the compiler error message means, workarounds
18439 are available - but they are all verbose. Explicit template arguments
18440 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
18441 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
18442 the first, so this would be extremely verbose. Therefore, constructing
18443 a <tt>basic_string</tt> from each C string is the simplest workaround.
18448 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
18449 impose performance costs that could be avoided by a library
18450 implementation taking C strings and dealing with them directly.
18451 (Currently, for replacement sources, C strings can be converted into
18452 iterator pairs at the cost of verbosity, but for format strings, there
18453 is no way to avoid constructing a <tt>basic_string</tt>.)
18463 We note that Boost already has these overloads. However, the proposed
18464 wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
18465 as well. We also note that this has impact on <tt>match_results::format</tt>,
18466 which may require further overloads.
18475 Daniel to tweak for us.
18479 2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>.
18485 This is solved by the proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>.
18490 2009-10 Santa Cruz:
18495 Leave Open. Though we believe this is solved by the proposed resolution
18496 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>.
18500 2010-01-27 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
18501 Rationale added below.
18506 <p><b>Rationale:</b></p>
18508 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>.
18512 <p><b>Proposed resolution:</b></p>
18515 Provide additional overloads for <tt>regex_replace()</tt>: one additional
18516 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
18517 additional overloads of the convenience form (one taking <tt>const charT*
18518 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
18519 charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]:
18523 <pre>template <class OutputIterator, class BidirectionalIterator,
18524 class traits, class charT>
18526 regex_replace(OutputIterator out,
18527 BidirectionalIterator first, BidirectionalIterator last,
18528 const basic_regex<charT, traits>& e,
18529 const basic_string<charT>& fmt,
18530 regex_constants::match_flag_type flags =
18531 regex_constants::match_default);
18533 <ins>template <class OutputIterator, class BidirectionalIterator,
18534 class traits, class charT>
18536 regex_replace(OutputIterator out,
18537 BidirectionalIterator first, BidirectionalIterator last,
18538 const basic_regex<charT, traits>& e,
18540 regex_constants::match_flag_type flags =
18541 regex_constants::match_default);</ins>
18544 <pre>template <class traits, class charT>
18545 basic_string<charT>
18546 regex_replace(const basic_string<charT>& s,
18547 const basic_regex<charT, traits>& e,
18548 const basic_string<charT>& fmt,
18549 regex_constants::match_flag_type flags =
18550 regex_constants::match_default);
18552 <ins>template <class traits, class charT>
18553 basic_string<charT>
18554 regex_replace(const basic_string<charT>& s,
18555 const basic_regex<charT, traits>& e,
18557 regex_constants::match_flag_type flags =
18558 regex_constants::match_default);</ins>
18560 <ins>template <class traits, class charT>
18561 basic_string<charT>
18562 regex_replace(const charT* s,
18563 const basic_regex<charT, traits>& e,
18564 const basic_string<charT>& fmt,
18565 regex_constants::match_flag_type flags =
18566 regex_constants::match_default);</ins>
18568 <ins>template <class traits, class charT>
18569 basic_string<charT>
18570 regex_replace(const charT* s,
18571 const basic_regex<charT, traits>& e,
18573 regex_constants::match_flag_type flags =
18574 regex_constants::match_default);</ins>
18584 <h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
18585 <p><b>Section:</b> 26.5.1.4 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18586 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18587 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
18588 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18589 <p><b>Discussion:</b></p>
18591 The 3rd table row in 26.5.1.4 [rand.req.eng]/3 requires random number engines to accept any
18592 arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently
18593 used for seeding the state of the engine. The requirement stated as "Creates an engine with
18594 initial state determined by <tt>static_cast<X::result_type>(s)</tt>" forces random number engines
18595 to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion
18596 of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits
18597 of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems
18598 to be inappropriate for many modern random number generators, in particular F2-linear or
18599 cryptographic ones, which operate on an internal bit array that in principle is independent of the
18600 type of numbers returned.
18604 <b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an
18605 engine with initial state determined by <tt>static_cast<UintType>(s)</tt>, where <tt>UintType</tt> is an
18606 implementation specific unsigned integer type."
18610 Additionally, the definition of s in 26.5.1.4 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
18614 Similarly, the type of the seed in 26.5.1.5 [rand.req.adapt]/3 e) could be left unspecified.
18618 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18619 for further discussion.
18623 Stephan Tolksdorf adds pre-Bellevue:
18629 In reply to the discussion in
18630 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18631 regarding this issue:
18634 The descriptions of all engines and engine adaptors given in sections
18635 26.5.3 [rand.eng] and 26.5.4 [rand.adapt] already specify the concrete
18636 types of the integer arguments for seeding. Hence, relaxing the general
18637 requirement in 26.5.1.4 [rand.req.eng] would not affect portability and
18638 reproducibility of the standard library. Furthermore, it is not clear to
18639 me what exactly the guarantee "with initial state determined by
18640 <tt>static_cast<X::result_type>(s)</tt>" is useful for. On the other hand,
18641 relaxing the requirement would allow developers to implement other
18642 random number engines that do not have to cast all arithmetic seed
18643 arguments to their result_types.
18653 Propose close NAD for the reasons given in N2424.
18659 <p><b>Proposed resolution:</b></p>
18661 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18662 for further discussion.
18666 Stephan Tolksdorf adds pre-Bellevue:
18672 Change row 3 of table 105 "Random number engine requirements" in 26.5.1.4 [rand.req.eng]/3
18676 Creates an engine with initial state determined by
18677 <tt><del>static_cast<X::result_type>(</del>s<del>)</del></tt>
18681 Similarly, change 26.5.1.5 [rand.req.adapt]/3 e)
18685 When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt>
18686 <ins>of arithmetic type (3.9.1)</ins>, ...
18697 <h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
18698 <p><b>Section:</b> 26.5.1.5 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18699 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18700 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18701 <p><b>Discussion:</b></p>
18703 If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base
18704 engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is
18705 qualified as constant, this procedure will ef fectively initialize all base engines with the same seed
18706 (though the resulting state might still dif fer to a certain degree if the engines are of different types).
18707 It is not clear whether this mode of operation is in general appropriate, hence -- as far as the
18708 stated requirements are of general nature and not just specific to the engine adaptors provided by
18709 the library -- it might be better to leave the behaviour unspecified, since the current definition of
18710 <tt>seed_seq</tt> does not allow for a generally satisfying specification.
18714 <b>Posssible resolution:</b> [As above]
18718 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18719 for further discussion.
18728 Close NAD for the reasons given in N2424.
18733 <p><b>Proposed resolution:</b></p>
18735 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18736 for the proposed resolution.
18744 <h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
18745 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18746 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18747 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
18748 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18749 <p><b>Discussion:</b></p>
18751 The proper way to seed random number engines seems to be the most frequently
18752 discussed issue of the 26.5 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather
18753 general and probably sufficient for most situations, it is unlikely to be optimal in every case (one
18754 problem was pointed out in point T5 above). In some situations it might, for instance, be better to
18755 seed the state with a cryptographic generator.
18758 In my opinion this is a pretty strong argument for extending the standard with a simple facility to
18759 customize the seeding procedure. This could, for example, be done with the following minimal
18764 <b>Possible resolution:</b>
18769 Turn the interface specification of 26.5.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the
18770 exact behaviour of the constructors and the randomize method are left unspecified and where the
18771 const qualification for randomize is removed. Classes implementing this interface are additionally
18772 required to specialize the traits class in c).
18775 Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
18779 Supplement the <tt>seed_seq</tt> with a traits class
18781 <blockquote><pre>template <typename T>
18782 struct is_seed_seq { static const bool value = false; }
18783 </pre></blockquote>
18784 <p>and the specialization</p>
18785 <blockquote><pre>template <>
18786 struct is_seed_seq<seed_seq> { static const bool value = true; }
18787 </pre></blockquote>
18788 <p>which users can supplement with further specializations.</p>
18791 Change 26.5.1.4 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and
18792 modify the constructors and seed methods in 26.5.3 [rand.eng] appropriately (the actual implementation
18793 could be done using the SFINAE technique).
18803 See N2424. Close NAD but note that "conceptizing" the library may cause
18804 this problem to be solved by that route.
18808 <p><b>Proposed resolution:</b></p>
18810 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18811 for the proposed resolution.
18819 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
18820 <p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
18821 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18822 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
18823 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
18824 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
18825 <p><b>Discussion:</b></p>
18827 X [rand.dist.samp.genpdf] describes the interface for a distribution template that is
18828 meant to simulate random numbers from any general distribution given only the density and the
18829 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
18830 of correctly and efficiently implementing the described functionality. From what I know, this is
18831 essentially an unsolved research problem. Existing algorithms either require more knowledge
18832 about the distribution and the problem domain or work only under very limited circumstances.
18833 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
18834 generality, and in any case, testing and customer support for such a library feature would be a
18839 <b>Possible resolution:</b> For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
18849 Disagreement persists.
18852 Objection to this issue is that this function takes a general functor.
18853 The general approach would be to normalize this function, integrate it,
18854 and take the inverse of the integral, which is not possible in general.
18855 An example function is sin(1+n*x) -- for any spatial frequency that the
18856 implementor chooses, there is a value of n that renders that choice
18857 arbitrarily erroneous.
18860 Correction: The formula above should instead read 1+sin(n*x).
18863 Objector proposes the following possible compromise positions:
18867 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
18870 replace rand.disk.samp.genpdf with an extension to either or both of the discrete functions to take arguments that take a functor and number of points in place of the list of probabilities. Reference issues 793 and 794.
18877 <p><b>Proposed resolution:</b></p>
18879 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2813.pdf">N2813</a>
18880 for the proposed resolution.
18884 <p><b>Rationale:</b></p>
18886 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
18893 <h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
18894 <p><b>Section:</b> 26.5.1.6 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18895 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18897 <p><b>Discussion:</b></p>
18899 The requirement "P shall have a declaration of the form <tt>typedef X distribution_-
18900 type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient,
18901 because the child of a distribution class in general will not satisfy this requirement. In my opinion
18902 the benefits of having a typedef in the parameter class pointing back to the distribution class are
18903 not worth the hassle this requirement causes. [In my code base I never made use of the nested
18904 typedef but on several occasions could have profited from being able to use simple inheritance for
18905 the implementation of a distribution class.]
18909 <b>Proposed resolution:</b> I propose to drop this requirement.
18918 Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
18923 <p><b>Proposed resolution:</b></p>
18925 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18926 for the proposed resolution.
18934 <h3><a name="735"></a>735. Unfortunate naming</h3>
18935 <p><b>Section:</b> 26.5.8.2.2 [rand.dist.bern.bin], 26.5.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18936 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18937 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18938 <p><b>Discussion:</b></p>
18940 In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
18941 is very unfortunate. In virtually every internet reference, book and software implementation
18942 this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993)
18943 Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926,
18944 Mathematica and Matlab.
18948 Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual.
18949 The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
18953 Choosing unusual names for the parameters causes confusion among users and makes the
18954 interface unnecessarily inconvenient to use.
18958 <b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
18959 to <tt>n</tt> and <tt>r</tt>.
18968 In N2424. NAD It has been around for a while. It is hardly universal,
18969 there is prior art, and this would confuse people.
18973 <p><b>Proposed resolution:</b></p>
18975 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18976 for the proposed resolution.
18984 <h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
18985 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18986 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
18987 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
18988 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18989 <p><b>Discussion:</b></p>
18992 The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
18993 to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to
18994 divide each probability by the sum of all probabilities, as the sum will in practice almost never be
18995 exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to
18996 compute the standardized probabilities at all and could instead work with the non-standardized
18997 probabilities and the sum. If there was no standardization the user would just get back the
18998 probabilities that were previously supplied to the distribution object, which to me seems to be the
18999 more obvious solution.
19002 The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
19003 probabilities is larger than the maximum number representable by the IntType.
19008 <b>Possible resolution:</b> I propose to change the specification such that the non-standardized
19009 probabilities need to be returned and that an additional requirement is included for the number
19010 of probabilities to be smaller than the maximum of IntType.
19014 Stephan Tolksdorf adds pre-Bellevue:
19020 In reply to the discussion in
19021 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19025 Rescaled floating-point parameter vectors can not be expected to compare
19026 equal because of the limited precision of floating-point numbers.
19027 My proposal would at least guarantee that a parameter
19028 vector (of type double) passed into the distribution would compare equal
19029 with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do
19030 not understand why "the changed requirement would lead to a significant
19031 increase in the amount of state in the distribution object". A typical
19032 implementation's state would increase by exactly one number: the sum of
19033 all probabilities. The textual representation for serialization would
19034 not need to grow at all. Finally, the proposed replacement "<tt>0 < n <=
19035 numeric_limits<IntType>::max() + 1</tt>" makes the implementation
19036 unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::max()</tt>"
19048 In N2424. We agree with the observation and the proposed resolution to
19049 part b). We recommend the wording n > 0 be replaced with 0 < n
19050 numeric_limits::max() + 1. However, we disagree with part a), as it
19051 would interfere with the definition of parameters' equality. Further,
19052 the changed requirement would lead to a significant increase in the
19053 amount of state of the distribution object.
19057 As it stands now, it is convenient, and the changes proposed make it
19062 NAD. Part a the current behavior is desirable. Part b, any constructor
19063 can fail, but the rules under which it can fail do not need to be listed
19069 <p><b>Proposed resolution:</b></p>
19071 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19072 for the proposed resolution.
19076 Stephan Tolksdorf adds pre-Bellevue:
19082 In 26.5.8.5.1 [rand.dist.samp.discrete]:
19086 Proposed wording a):
19095 Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>
19099 and change in para. 5
19103 <i>Returns:</i> A <tt>vector<double></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose
19104 <tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del>
19105 <ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
19106 when invoked with argument <tt>k</tt> for <tt>k = 0,
19113 Proposed wording b):
19122 If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist
19123 of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a
19124 sequence <tt>w</tt> of length <tt>n <del>> 0</del></tt>
19125 <ins>such that <tt>0 < n <= numeric_limits<IntType>::max()</tt>,</ins>
19126 and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt>
19127 convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known
19128 as the weights . <i>-- end note</i>]
19140 <h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
19141 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19142 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
19143 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
19144 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19145 <p><b>Discussion:</b></p>
19148 The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies
19149 to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
19153 The design of the constructor
19155 <blockquote><pre>template <class InputIteratorB, class InputIteratorW>
19156 piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
19157 InputIteratorW firstW);
19158 </pre></blockquote>
19160 is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see
19161 any performance or convenience reasons that would justify the risks inherent in such a function
19162 interface, in particular the risk that input error might go unnoticed.
19168 <b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
19172 Stephan Tolksdorf adds pre-Bellevue:
19176 In reply to the discussion in
19177 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19178 I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>.
19187 In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
19191 <p><b>Proposed resolution:</b></p>
19193 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19194 for the proposed resolution.
19198 Stephan Tolksdorf adds pre-Bellevue:
19204 In 26.5.8.5.2 [rand.dist.samp.pconst]:
19208 Proposed wording a)
19216 Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>,
19217 <tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt>
19221 and change in para. 5
19225 A <tt>vector<result_type></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt>
19226 member returns <del><tt>p<sub>k</sub></tt></del>
19227 <ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
19228 when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt>
19234 Proposed wording b)
19239 Change both occurrences of
19243 "piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
19244 InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
19248 and change in para. 3
19252 <del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>,
19253 <tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any
19254 <tt>w<sub>k</sub></tt> for <tt>k >= n</tt> shall be ignored by the distribution</del>
19255 <ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element
19256 <tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins>
19270 <h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
19271 <p><b>Section:</b> 26.5.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
19272 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
19273 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.disc">issues</a> in [rand.adapt.disc].</p>
19274 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
19275 <p><b>Discussion:</b></p>
19277 Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class
19278 exposition should have type <tt>size_t</tt>, too.
19282 <p><b>Proposed resolution:</b></p>
19284 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19285 for the proposed resolution.
19293 <h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
19294 <p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19295 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
19296 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
19297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19298 <p><b>Discussion:</b></p>
19300 The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2
19301 R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in
19302 general) be computed at compile time. As this function template is performance critical, I propose
19303 to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
19307 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19308 for further discussion.
19317 In N2424. Close NAD as described there.
19322 <p><b>Proposed resolution:</b></p>
19324 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19325 for the proposed resolution.
19333 <h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
19334 <p><b>Section:</b> 20.9.10.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19335 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-09-27 <b>Last modified:</b> 2010-10-29</p>
19336 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
19337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19338 <p><b>Discussion:</b></p>
19340 The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
19344 According to the recent draft N2369, both the header memory synopsis
19345 of 20.9 [memory] and 20.9.10.2.11 [util.smartptr.getdeleter] declare:
19348 <blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
19349 </pre></blockquote>
19352 This allows to retrieve the pointer to a mutable deleter of a <tt>const
19353 shared_ptr</tt> (if that owns one) and therefore contradicts the usual
19354 philosophy that associated functors are either read-only (e.g.
19355 <tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
19356 the mutability of the owner (as seen for the both overloads of
19357 <tt>unique_ptr::get_deleter</tt>).
19358 Even the next similar counter-part of <tt>get_deleter</tt> - the two
19359 overloads of <tt>function::target</tt> in the class template function
19360 synopsis 20.8.14.2 [func.wrap.func] or in 20.8.14.2.5 [func.wrap.func.targ] - do
19361 properly mirror the const-state of the owner.
19364 <b>Possible proposed resolutions:</b>
19367 Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt>
19368 synopsis of 20.9 [memory] and in 20.9.10.2.11 [util.smartptr.getdeleter] by one of the
19369 following alternatives (A) or (B):
19374 Provide <b>only</b> the immutable variant. This would reflect the
19375 current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
19376 <tt>map::value_comp</tt>.
19378 <blockquote><pre>template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
19379 </pre></blockquote>
19382 Just remove the function.
19387 Alberto Ganesh Barbati adds:
19390 <ol type="A" start="3">
19393 Replace it with two functions:
19395 <blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&);
19396 template <class D, class T> bool has_deleter(shared_ptr<T> const&);
19397 </pre></blockquote>
19400 The first one would throw if <tt>D</tt> is the wrong type, while the latter would
19401 never throw. This approach would reflect the current praxis of
19402 <tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
19403 <tt>container::get_allocator()</tt> do.
19414 My favorite option is "not a defect". A, B and C break useful code.
19424 Concern this is similar to confusing "pointer to const" with "a constant pointer".
19428 <p><b>Proposed resolution:</b></p>
19437 <h3><a name="745"></a>745. copy_exception API slices.</h3>
19438 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19439 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
19440 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
19441 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
19442 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19443 <p><b>Discussion:</b></p>
19445 It could be I did not understand the design rationale, but I thought
19446 copy_exception would produce an exception_ptr to the most-derived (dynamic)
19447 type of the passed exception. Instead it slices, which appears to be less
19448 useful, and a likely source of FAQ questions in the future.
19451 (Peter Dimov suggests NAD)
19461 How could this be implemented in a way that the dynamic type is cloned?
19464 The feature is designed to create an exception_ptr from an object whose
19465 static type is identical to the dynamic type and thus there is no
19471 <p><b>Proposed resolution:</b></p>
19480 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
19481 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19482 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
19483 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
19484 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19485 <p><b>Discussion:</b></p>
19487 We have 3 separate type traits to identify classes supporting no-throw
19488 operations, which are very useful when trying to provide exception safety
19489 guarantees. However, I'm not entirely clear on what the current wording
19490 requires of a conforming implementation. To quote from
19491 <tt>has_nothrow_default_constructor</tt>:
19494 or <tt>T</tt> is a class type with a default constructor that is known not to throw
19498 What level of magic do we expect to deduce if this is known?
19504 <blockquote><pre>struct test{
19508 </pre></blockquote>
19510 Should I expect a conforming compiler to
19511 <tt>assert( has_nothrow_constructor<test>::value )</tt>
19514 Is this a QoI issue?
19517 Should I expect to 'know' only if-and-only-if there is an inline definition
19521 Should I never expect that to be true, and insist that the user supplies an
19522 empty throw spec if they want to assert the no-throw guarantee?
19525 It would be helpful to maybe have a footnote explaining what is required,
19526 but right now I don't know what to suggest putting in the footnote.
19529 (agreement since is that trivial ops and explicit no-throws are required.
19530 Open if QoI should be allowed to detect further)
19539 This looks like a QoI issue.
19540 In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
19541 Move to OPEN. Need to talk to Core about this.
19559 <p><b>Proposed resolution:</b></p>
19568 <h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
19569 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19570 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
19571 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
19572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19573 <p><b>Discussion:</b></p>
19575 I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
19576 sufficient requirement to be classified as abstract?
19579 For instance, is the following (non-polymorphic) type considered abstract?
19581 <blockquote><pre>struct abstract {
19584 abstract( abstract const & ) {}
19587 </pre></blockquote>
19589 (Suggested that this may be NAD, with an editorial fix-up from Pete on the
19590 core wording to make clear that abstract requires a pure virtual function)
19594 <p><b>Proposed resolution:</b></p>
19596 Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
19604 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
19605 implicitly convertible, so explicit constructors are ignored.</h3>
19606 <p><b>Section:</b> 20.7.6 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
19607 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
19608 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
19609 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
19610 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a></p>
19611 <p><b>Discussion:</b></p>
19613 With the pending arrival of explicit conversion functions though, I'm
19614 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
19623 Alisdair is considering preparing a paper listing a number of missing
19624 type traits, and feels that it might be useful to handle them all
19625 together rather than piecemeal. This would affect issue 719 and 750.
19626 These two issues should move to OPEN pending AM paper on type traits.
19635 Duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a> (for our purposes).
19639 Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
19645 <p><b>Proposed resolution:</b></p>
19653 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
19654 <p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19655 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
19656 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
19657 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19658 <p><b>Discussion:</b></p>
19660 A number of vector<bool> members take const bool& as arguments.
19661 Is there any chance we could change them to pass-by-value or would I
19662 be wasting everyone's time if wrote up an issue?
19672 As we understand it, the original requester (Martin Sebor) would like
19673 for implementations to be permitted to pass-by-value. Alisdair suggests
19674 that if this is to be resolved, it should be resolved more generally,
19675 e.g. in other containers as well.
19678 We note that this would break ABI. However, we also suspect that this
19679 might be covered under the "as-if" rule in section 1.9.
19682 Many in the group feel that for vector<bool>, this is a "don't care",
19683 and that at this point in the process it's not worth the bandwidth.
19686 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
19687 now in the working paper -- is related to this, though not a duplicate.
19690 Moving to Open with a task for Alisdair to craft a informative note to
19691 be put whereever appropriate in the WP. This note would clarify places
19692 where pass-by-const-ref can be transformed to pass-by-value under the
19704 This is really a clause 17 issue, rather than something specific to vector<bool>.
19707 Move to Open. Alisdair to provide a resolution. Alternately, Howard can
19708 close this as NAD and then open a new issue to handle the general issue
19709 (rather than the vector<bool> one).
19712 Howard: Haven't yet opened new issue. Lacking wording for it.
19722 NAD. Insufficient motivation to make any changes.
19726 <p><b>Proposed resolution:</b></p>
19735 <h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
19736 <p><b>Section:</b> 20.9.8.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
19737 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-10-15 <b>Last modified:</b> 2010-10-29</p>
19738 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
19739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
19740 <p><b>Discussion:</b></p>
19742 14882-2003, [lib.uninitialized.copy] is currently written as follows:
19746 <pre>template <class InputIterator, class ForwardIterator>
19747 ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
19748 ForwardIterator <i>result</i>);
19752 -1- <i>Effects:</i>
19754 <blockquote><pre>for (; first != last; ++result, ++first)
19755 new (static_cast<void*>(&*result))
19756 typename iterator_traits<ForwardIterator>::value_type(*first);
19757 </pre></blockquote>
19759 -2- <i>Returns:</i> <tt><i>result</i></tt>
19765 similarily for N2369, and its corresponding section
19766 20.9.8.2 [uninitialized.copy].
19770 It's not clear to me what the return clause is supposed to mean, I see
19772 possible interpretations:
19777 The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
19778 function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
19779 <tt><i>result</i></tt>].
19780 This seems somewhat implied by recognizing that both the function
19782 and the name used in the clause do have the same italic font.
19785 The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
19787 preceding effects clause. This is in fact what all implementations I
19789 do (and which is probably it's intend, because it matches the
19790 specification of <tt>std::copy</tt>).
19795 The problem is: I see nothing in the standard which grants that this
19797 is correct, specifically [lib.structure.specifications] or
19798 17.5.1.4 [structure.specifications]
19799 resp. do not clarify which "look-up" rules apply for names found in
19801 of the detailed specifications - Do they relate to the corresponding
19803 to the effects clause (or possibly other elements)? Fortunately most
19805 descriptions are unambigious in this regard, e.g. this problem does
19807 for <tt>std::copy</tt>.
19812 <p><b>Proposed resolution:</b></p>
19814 Change the wording of the return clause to say (20.9.8.2 [uninitialized.copy]):
19819 -2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
19830 Resolution: NAD editorial -- project editor to decide if change is
19831 worthwhile. Concern is that there are many other places this might
19839 <h3><a name="756"></a>756. Container adaptors push</h3>
19840 <p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
19841 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2010-10-29</p>
19842 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
19843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
19844 <p><b>Discussion:</b></p>
19846 After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
19847 of the "emplace" type. At variance with that, still in n2461, we have
19848 two separate overloads, the C++03 one + one taking an rvalue reference
19849 in the container adaptors. Therefore, simply from a consistency point of
19850 view, I was wondering whether the container adaptors should be aligned
19851 with the specifications of the sequence container themselves: thus have
19852 a single <tt>push</tt> along the lines:
19855 <blockquote><pre>template<typename... _Args>
19857 push(_Args&&... __args)
19858 { c.push_back(std::forward<_Args>(__args)...); }
19859 </pre></blockquote>
19862 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19867 <p><b>Proposed resolution:</b></p>
19869 Change 23.5.1.1 [queue.defn]:
19872 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
19873 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
19874 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
19875 </pre></blockquote>
19878 Change 23.5.2 [priority.queue]:
19881 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
19882 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
19883 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
19884 </pre></blockquote>
19887 Change 23.5.2.3 [priqueue.members]:
19891 <pre><del>void push(const value_type& x);</del>
19895 <del><i>Effects:</i></del>
19897 <blockquote><pre><del>c.push_back(x);</del>
19898 <del>push_heap(c.begin(), c.end(), comp);</del>
19899 </pre></blockquote>
19902 <pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>);
19908 <blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
19909 push_heap(c.begin(), c.end(), comp);
19910 </pre></blockquote>
19915 Change 23.5.3.1 [stack.defn]:
19918 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
19919 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
19920 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
19921 </pre></blockquote>
19925 <p><b>Rationale:</b></p>
19928 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
19936 <h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
19937 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
19938 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-04 <b>Last modified:</b> 2010-10-29</p>
19939 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
19940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
19941 <p><b>Discussion:</b></p>
19943 In the synopsis 23.4.1 [vector], there is the signature:
19946 <blockquote><pre>void insert(const_iterator position, size_type n, T&& x);
19947 </pre></blockquote>
19953 <blockquote><pre>iterator insert(const_iterator position, T&& x);
19954 </pre></blockquote>
19957 23.4.1.4 [vector.modifiers] is fine.
19962 <p><b>Proposed resolution:</b></p>
19964 Change the synopsis in 23.4.1 [vector]:
19967 <blockquote><pre>iterator insert(const_iterator position, const T& x);
19968 <ins>iterator insert(const_iterator position, T&& x);</ins>
19969 void insert(const_iterator position, size_type n, const T& x);
19970 <del>void insert(const_iterator position, size_type n, T&& x);</del>
19971 </pre></blockquote>
19978 <h3><a name="760"></a>760. The emplace issue</h3>
19979 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
19980 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-11 <b>Last modified:</b> 2010-10-29</p>
19981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
19982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
19983 <p><b>Discussion:</b></p>
19985 In an emplace member function the function parameter pack may be bound
19986 to a priori unlimited number of objects: some or all of them can be
19987 elements of the container itself. Apparently, in order to conform to the
19988 blanket statement 23.2 [container.requirements]/11, the
19989 implementation must check all of them for that possibility. A possible
19990 solution can involve extending the exception in 23.2 [container.requirements]/12 also to the emplace member. As a
19991 side note, the <tt>push_back</tt> and <tt>push_front</tt> member
19992 functions are luckily not affected by this problem, can be efficiently
19997 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
20008 The proposed addition (13) is partially redundant with the existing
20009 paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
20010 does it not cover subelements and pointers?
20013 Resolution: Alan Talbot to rework language, then set state to Review.
20024 The problem is broader than emplace. The LWG doesn't
20025 feel that it knows how to write wording that prohibits all of the
20026 problematic use cases at this time.
20035 <p><b>Proposed resolution:</b></p>
20037 Add after 23.2 [container.requirements]/12:
20042 -12- Objects passed to member functions of a container as rvalue
20043 references shall not be elements of that container. No diagnostic
20048 -13- Objects bound to the function parameter pack of the
20049 <tt>emplace</tt> member function shall not be elements or sub-objects of
20050 elements of the container. No diagnostic required.
20062 <h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
20063 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20064 <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-04 <b>Last modified:</b> 2010-10-29</p>
20065 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
20066 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
20067 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20068 <p><b>Discussion:</b></p>
20070 The associative containers provide 2 overloads of <tt>emplace()</tt>:
20073 <blockquote><pre>template <class... Args> pair<iterator, bool> emplace(Args&&... args);
20074 template <class... Args> iterator emplace(const_iterator position, Args&&... args);
20075 </pre></blockquote>
20078 This is a problem if you mean the first overload while passing
20079 a <tt>const_iterator</tt> as first argument.
20083 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
20095 This can be disambiguated by passing "begin" as the first argument in
20096 the case when the non-default choice is desired. We believe that desire
20100 Resolution: Change state to NAD.
20104 <p><b>Proposed resolution:</b></p>
20106 Rename one of the two overloads.
20107 For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
20115 <h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
20116 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20117 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-29 <b>Last modified:</b> 2010-10-29</p>
20118 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
20119 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
20120 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20121 <p><b>Discussion:</b></p>
20123 A major attribute of the unordered containers is that iterating
20124 though them inside a bucket is very fast while iterating between buckets
20125 can be much slower. If an unordered container has a low load factor,
20126 iterating between the last iterator in one bucket and the next iterator,
20127 which is in another bucket, is <tt>O(bucket_count())</tt> which may be much
20128 larger than <tt>O(size())</tt>.
20131 If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an
20132 object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns
20133 <tt>pair<B::iterator, B::iterator></tt>. Consider the following code:
20136 <blockquote><pre>B::iterator lb, ub;
20137 tie(lb, ub) = b.equal_range(k);
20138 for (B::iterator it = lb; it != ub; ++it) {
20139 // Do something with *it
20141 </pre></blockquote>
20144 If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least
20145 on element whose key is equivalent to <tt>k</tt>), then every iterator in the
20146 half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely
20147 either be in a different bucket or be equal to <tt>b.end()</tt>. In either case,
20148 iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than
20149 iterating through the rest of the range.
20152 If instead of returning <tt>pair<iterator, iterator></tt>, <tt>equal_range</tt> were to
20153 return <tt>pair<local_iterator, local_iterator></tt>, then <tt>ub</tt> (which, like <tt>lb</tt>,
20154 would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the
20155 same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt>
20156 or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>.
20157 This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every
20158 iteration would be constant time.
20167 The proposed resolution breaks consistency with other container types
20168 for dubious benefit, and iterators are already constant time.
20173 <p><b>Proposed resolution:</b></p>
20175 Change the entry for <tt>equal_range</tt> in Table 93 (23.2.5 [unord.req]) as follows:
20179 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
20183 <td><tt>b.equal_range(k)</tt></td>
20184 <td><tt>pair<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></tt> for <tt>const b</tt>.</td>
20185 <td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td>
20186 <td>Average case Θ<tt>(b.count(k))</tt>. Worst case Θ<tt>(b.size())</tt>. </td>
20195 <h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
20196 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
20197 <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2010-10-29</p>
20198 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
20199 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
20200 <p><b>Discussion:</b></p>
20202 Playing with g++'s C++0X mode, I noticed that the following
20203 code, which used to compile:
20206 <blockquote><pre>#include <vector>
20210 std::vector<char *> v;
20213 </pre></blockquote>
20216 now fails with the following error message:
20220 .../include/c++/4.3.0/ext/new_allocator.h: In member function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, _Args&& ...) [with _Args = int, _Tp = char*]':
20221 .../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with _Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
20222 test.cpp:6: instantiated from here
20223 .../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid conversion from 'int' to 'char*'
20227 As far as I know, g++ follows the current draft here.
20230 Does the committee really intend to break compatibility for such cases?
20240 I just noticed that <tt>std::pair</tt> has the same issue.
20241 The following now fails with GCC's -std=c++0x mode:
20244 <blockquote><pre>#include <utility>
20248 std::pair<char *, char *> p (0,0);
20250 </pre></blockquote>
20253 I have not made any general audit for such problems elsewhere.
20258 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
20269 Motivation is to handle the old-style int-zero-valued NULL pointers.
20270 Problem: this solution requires concepts in some cases, which some users
20271 will be slow to adopt. Some discussion of alternatives involving
20272 prohibiting variadic forms and additional library-implementation
20276 Discussion of "perfect world" solutions, the only such solution put
20277 forward being to retroactively prohibit use of the integer zero for a
20278 NULL pointer. This approach was deemed unacceptable given the large
20279 bodies of pre-existing code that do use integer zero for a NULL pointer.
20282 Another approach is to change the member names. Yet another approach is
20283 to forbid the extension in absence of concepts.
20286 Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
20287 paper to be produced by Alan Talbot in time for review at the 2008
20288 meeting in France. Once this paper is produced, these issues will be
20295 <p><b>Proposed resolution:</b></p>
20297 Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
20303 <th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
20308 <tt>a.push_front(t)</tt>
20314 <tt>a.insert(a.begin(), t)</tt><br>
20315 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
20318 <tt>list, deque</tt>
20324 <tt>a.push_front(rv)</tt>
20330 <tt>a.insert(a.begin(), rv)</tt><br>
20331 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
20334 <tt>list, deque</tt>
20340 <tt>a.push_back(t)</tt>
20346 <tt>a.insert(a.end(), t)</tt><br>
20347 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
20350 <tt>list, deque, vector, basic_string</tt>
20356 <tt>a.push_back(rv)</tt>
20362 <tt>a.insert(a.end(), rv)</tt><br>
20363 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
20366 <tt>list, deque, vector, basic_string</tt>
20374 Change the synopsis in 23.3.2 [deque]:
20377 <blockquote><pre><ins>void push_front(const T& x);</ins>
20378 <ins>void push_front(T&& x);</ins>
20379 <ins>void push_back(const T& x);</ins>
20380 <ins>void push_back(T&& x);</ins>
20381 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
20382 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20383 </pre></blockquote>
20386 Change 23.3.2.3 [deque.modifiers]:
20389 <blockquote><pre><ins>void push_front(const T& x);</ins>
20390 <ins>void push_front(T&& x);</ins>
20391 <ins>void push_back(const T& x);</ins>
20392 <ins>void push_back(T&& x);</ins>
20393 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
20394 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20395 </pre></blockquote>
20398 Change the synopsis in 23.3.4 [list]:
20401 <blockquote><pre><ins>void push_front(const T& x);</ins>
20402 <ins>void push_front(T&& x);</ins>
20403 <ins>void push_back(const T& x);</ins>
20404 <ins>void push_back(T&& x);</ins>
20405 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
20406 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20407 </pre></blockquote>
20410 Change 23.3.4.3 [list.modifiers]:
20413 <blockquote><pre><ins>void push_front(const T& x);</ins>
20414 <ins>void push_front(T&& x);</ins>
20415 <ins>void push_back(const T& x);</ins>
20416 <ins>void push_back(T&& x);</ins>
20417 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
20418 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20419 </pre></blockquote>
20422 Change the synopsis in 23.4.1 [vector]:
20425 <blockquote><pre><ins>void push_back(const T& x);</ins>
20426 <ins>void push_back(T&& x);</ins>
20427 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20428 </pre></blockquote>
20431 Change 23.4.1.4 [vector.modifiers]:
20434 <blockquote><pre><ins>void push_back(const T& x);</ins>
20435 <ins>void push_back(T&& x);</ins>
20436 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
20437 </pre></blockquote>
20442 <p><b>Rationale:</b></p>
20445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
20449 If there is still an issue with pair, Howard should submit another issue.
20457 <h3><a name="773"></a>773. issues with random</h3>
20458 <p><b>Section:</b> 26.5.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20459 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-01-14 <b>Last modified:</b> 2010-10-29</p>
20460 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
20461 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20462 <p><b>Discussion:</b></p>
20465 26.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default
20466 max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value
20467 is arbitrary at best and shouldn't be lightly changed because
20468 it breaks backward compatibility.
20472 26.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can
20473 provide on construction or <tt>operator()</tt>, set, and get. But there
20474 is not even a hint of what this might be for.
20478 26.5.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
20492 <p><b>Proposed resolution:</b></p>
20501 <h3><a name="784"></a>784. unique_lock::release</h3>
20502 <p><b>Section:</b> 30.4.2.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20503 <b>Submitter:</b> Constantine Sapuntzakis <b>Opened:</b> 2008-02-02 <b>Last modified:</b> 2010-10-29</p>
20504 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20505 <p><b>Discussion:</b></p>
20507 <tt>unique_lock::release</tt> will probably lead to many mistakes where people
20508 call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the
20509 boost pre-1.35 threads library last week.
20513 In many threading libraries, a call with <tt>release</tt> in it unlocks the
20514 lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
20518 I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the
20519 symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to
20520 lock the mutex. So I'm left to remember whether to call <tt>release</tt> or
20521 <tt>unlock</tt> during the few times I need to release the mutex before the scope
20522 ends. If I get it wrong, the compiler doesn't warn me.
20526 An alternative name for release may be <tt>disown</tt>.
20530 This might be a rare case where usability is hurt by consistency with
20531 the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>).
20540 Change a name from release to disown. However prior art uses the release
20541 name. Compatibility with prior art is more important that any possible
20542 benefit such a change might make. We do not see the benefit for
20547 <p><b>Proposed resolution:</b></p>
20549 Change the synopsis in 30.4.2.2 [thread.lock.unique]:
20552 <blockquote><pre>template <class Mutex>
20557 mutex_type* <del>release</del> <ins>disown</ins>();
20560 </pre></blockquote>
20563 Change 30.4.2.2.3 [thread.lock.unique.mod]:
20566 <blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
20567 </pre></blockquote>
20574 <h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
20575 <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20576 <b>Submitter:</b> John Maddock <b>Opened:</b> 2008-01-15 <b>Last modified:</b> 2010-10-29</p>
20577 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20578 <p><b>Discussion:</b></p>
20580 Table 16 of TR1 requires that all Pseudo Random Number generators have a
20583 <blockquote><pre>seed(integer-type s)
20584 </pre></blockquote>
20587 member function that is equivalent to:
20590 <blockquote><pre>mygen = Generator(s)
20591 </pre></blockquote>
20594 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
20597 <blockquote><pre>template <class Gen>
20599 </pre></blockquote>
20602 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
20606 So... is this a bug in TR1?
20610 This is a real issue BTW, since the Boost implementation does adhere to the requirements of Table 16, while at least one commercial implementation does not and follows a strict adherence to sections 5.1.4.5 and 5.1.4.6 instead.
20619 Both engines do have the necessary
20620 constructor, therefore the omission of the <tt>seed()</tt> member
20621 functions appears to be an oversight.
20625 Post Summit Daniel adds:
20630 Recommend NAD: <tt>xor_combine</tt> does no longer exist and <tt>discard_block[_engine]</tt>
20631 has now the required seed overload accepting a <tt>result_type</tt>, which shall be an
20632 unsigned integral type.
20640 Move to NAD as recommended.
20644 <p><b>Proposed resolution:</b></p>
20654 <h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
20655 <p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20656 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
20657 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
20658 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20659 <p><b>Discussion:</b></p>
20661 <tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&)</tt> don't say what
20662 happens to each of the sub-engine seeds. (Should probably do the same
20663 to both, unlike TR1.)
20672 Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>.
20677 <p><b>Proposed resolution:</b></p>
20684 <h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</h3>
20685 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20686 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
20687 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
20688 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20689 <p><b>Discussion:</b></p>
20691 <tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>,
20692 just like <tt>discrete_distribution</tt>. (There's no real use for weights divided
20703 Fermilab does not agree with this summary. As defined in the equation in
20704 26.4.8.5.2/4, the quantities are indeed probability densities not
20705 probabilities. Because we view this distribution as a parameterization
20706 of a *probability density function*, we prefer to work in terms of
20707 probability densities.
20711 We don't think this should be changed.
20715 If there is a technical argument about why the implementation dealing
20716 with these values can't be as efficient as one dealing with
20717 probabilities, we might reconsider. We don't care about this one member
20718 function being somewhat more or less efficient; we care about the size
20719 of the distribution object and the speed of the calls to generate
20726 <p><b>Proposed resolution:</b></p>
20729 Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]:
20732 <blockquote><pre>template <class RealType = double>
20733 class piecewise_constant_distribution
20737 vector<double> <del>densities</del> <ins>probabilities</ins>() const;
20740 </pre></blockquote>
20743 Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
20746 <blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const;
20747 </pre></blockquote>
20755 <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
20756 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
20757 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
20758 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
20759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
20760 <p><b>Discussion:</b></p>
20762 <tt>discrete_distribution</tt> should have a constructor like:
20765 <blockquote><pre>template<class _Fn>
20766 discrete_distribution(result_type _Count, double _Low, double _High,
20768 </pre></blockquote>
20771 (Makes it easier to fill a histogram with function values over a range.)
20780 How do you specify the function so that it does not return negative
20781 values? If you do it is a bad construction. This requirement is already
20782 there. Where in each bin does one evaluate the function? In the middle.
20783 Need to revisit tomorrow.
20793 Bill is not requesting this.
20796 Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
20797 function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
20798 return 0 everywhere it is sampled.
20801 Jens: lambda expressions are rvalues
20804 Add a library issue to provide an
20805 <tt>initializer_list<double></tt> constructor for
20806 <tt>discrete_distribution</tt>.
20809 Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
20810 use <tt>std::ref</tt> to wrap giant-state function objects.
20813 Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
20816 Daniel to draft wording.
20821 Pre San Francisco, Daniel provided wording:
20826 The here proposed changes of the WP refer to the current state of
20827 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
20828 During the Sophia Antipolis meeting two different proposals came up
20829 regarding the functor argument type, either by value or by rvalue-reference.
20830 For consistence with existing conventions (state-free algorithms and the
20831 <tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
20832 function argument that is provided by value. If severe concerns exists that
20833 stateful functions would be of dominant relevance, it should be possible to
20834 replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part
20835 of an editorial process.
20840 <p><b>Proposed resolution:</b></p>
20842 <p><b>Non-concept version of the proposed resolution</b></p>
20847 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
20848 <em>before</em> the member declaration
20851 <blockquote><pre>explicit discrete_distribution(const param_type& parm);
20852 </pre></blockquote>
20859 <blockquote><pre>template<typename Func>
20860 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20861 </pre></blockquote>
20866 Between p.4 and p.5 insert a series of new paragraphs as part of the
20867 new member description::
20869 <blockquote><pre>template<typename Func>
20870 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20874 <i>Complexity:</i> Exactly nf invocations of fw.
20881 fw shall be callable with one argument of type double, and shall
20882 return values of a type convertible to double;</li>
20884 <li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
20885 <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
20886 and non-infinity;</li>
20888 <li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20896 <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
20897 consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
20900 <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
20902 <blockquote><pre>For each k = 0, . . . ,n-1, calculates:
20903 <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
20904 <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
20905 </pre></blockquote>
20908 <p>Constructs a discrete_distribution object with probabilities:</p>
20909 <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
20910 </pre></blockquote>
20917 <p><b>Concept version of the proposed resolution</b></p>
20923 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
20924 <em>before</em> the member declaration
20927 <blockquote><pre>explicit discrete_distribution(const param_type& parm);
20928 </pre></blockquote>
20935 <blockquote><pre>template<Callable<auto, double> Func>
20936 requires Convertible<Func::result_type, double>
20937 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20938 </pre></blockquote>
20943 Between p.4 and p.5 insert a series of new paragraphs as part of the
20944 new member description::
20946 <blockquote><pre>template<Callable<auto, double> Func>
20947 requires Convertible<Func::result_type, double>
20948 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20952 <i>Complexity:</i> Exactly nf invocations of fw.
20958 <li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
20959 <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
20960 and non-infinity;</li>
20962 <li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20970 <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
20971 consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
20974 <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
20976 <blockquote><pre>For each k = 0, . . . ,n-1, calculates:
20977 <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
20978 <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
20979 </pre></blockquote>
20982 <p>Constructs a discrete_distribution object with probabilities:</p>
20983 <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
20984 </pre></blockquote>
20993 <p><b>Rationale:</b></p>
20995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
21002 <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
21003 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
21004 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
21005 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
21006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
21007 <p><b>Discussion:</b></p>
21009 <tt>piecewise_constant_distribution</tt> should have a constructor like:
21012 <blockquote><pre>template<class _Fn>
21013 piecewise_constant_distribution(size_t _Count,
21014 _Ty _Low, _Ty _High, _Fn& _Func);
21015 </pre></blockquote>
21018 (Makes it easier to fill a histogram with function values over a range.
21019 The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>) make a sensible replacement for
21020 <tt>general_pdf_distribution</tt>.)
21030 Marc: uses variable width of bins and weight for each bin. This is not
21031 giving enough flexibility to control both variables.
21034 Add a library issue to provide an constructor taking an
21035 <tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
21038 Daniel to draft wording.
21043 Pre San Francisco, Daniel provided wording.
21048 The here proposed changes of the WP refer to the current state of
21049 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
21050 For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, the author decided to propose a function
21051 argument that is provided by value. The issue proposes a c'tor signature,
21052 that does not take advantage of the full flexibility of
21053 <tt>piecewise_constant_distribution</tt>,
21054 because it restricts on a constant bin width, but the use-case seems to
21055 be popular enough to justify it's introduction.
21060 <p><b>Proposed resolution:</b></p>
21062 <p><b>Non-concept version of the proposed resolution</b></p>
21067 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
21068 just <em>before</em> the member declaration
21071 <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
21072 </pre></blockquote>
21076 <blockquote><pre>template<typename Func>
21077 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21078 </pre></blockquote>
21083 Between p.4 and p.5 insert a new sequence of paragraphs nominated
21084 below as [p5_1], [p5_2],
21085 [p5_3], and [p5_4] as part of the new member description:
21088 <blockquote><pre>template<typename Func>
21089 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21093 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
21096 [p5_2] <i>Requires:</i>
21099 <li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
21100 return values of a type convertible to double;
21103 For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
21104 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
21107 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
21108 0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
21112 [p5_3] <i>Effects:</i>
21119 sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
21120 <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
21121 value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
21122 <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
21123 <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
21130 <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
21131 <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
21133 <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
21134 <blockquote><pre>for each k = 0, . . . ,n-1, calculates:
21135 <tt><i>dx<sub>k</sub></i></tt> = k * deltax
21136 <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
21137 <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
21138 <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
21139 </pre></blockquote>
21142 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
21147 Constructs a <tt>piecewise_constant_distribution</tt> object with
21148 the above computed sequence <tt>b</tt> as the interval boundaries
21149 and with the probability densities:
21151 <blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
21152 </pre></blockquote>
21156 [p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
21157 known as the <i>bins</i> of a histogram. <i>-- end note</i>]
21164 <p><b>Concept version of the proposed resolution</b></p>
21169 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
21170 just <em>before</em> the member declaration
21173 <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
21174 </pre></blockquote>
21178 <blockquote><pre>template<Callable<auto, RealType> Func>
21179 requires Convertible<Func::result_type, double>
21180 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21181 </pre></blockquote>
21186 Between p.4 and p.5 insert a new sequence of paragraphs nominated
21187 below as [p5_1], [p5_2],
21188 [p5_3], and [p5_4] as part of the new member description:
21191 <blockquote><pre>template<Callable<auto, RealType> Func>
21192 requires Convertible<Func::result_type, double>
21193 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21197 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
21200 [p5_2] <i>Requires:</i>
21204 For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
21205 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
21208 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
21209 0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
21213 [p5_3] <i>Effects:</i>
21220 sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
21221 <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
21222 value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
21223 <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
21224 <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
21231 <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
21232 <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
21234 <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
21235 <blockquote><pre>for each k = 0, . . . ,n-1, calculates:
21236 <tt><i>dx<sub>k</sub></i></tt> = k * deltax
21237 <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
21238 <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
21239 <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
21240 </pre></blockquote>
21243 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
21248 Constructs a <tt>piecewise_constant_distribution</tt> object with
21249 the above computed sequence <tt>b</tt> as the interval boundaries
21250 and with the probability densities:
21252 <blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
21253 </pre></blockquote>
21257 [p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
21258 known as the <i>bins</i> of a histogram. <i>-- end note</i>]
21267 <p><b>Rationale:</b></p>
21269 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
21276 <h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
21277 <p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
21278 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
21279 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
21280 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
21281 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a></p>
21282 <p><b>Discussion:</b></p>
21284 <tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
21285 adaptive numerical integration.)
21289 Stephan Tolksdorf notes:
21294 This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>.
21298 <p><b>Proposed resolution:</b></p>
21306 <h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3>
21307 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21308 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
21309 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
21310 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21311 <p><b>Discussion:</b></p>
21313 The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be
21314 61839128582725. We get 192113843633948. (Note that the underlying
21315 generator was changed in Kona.)
21324 Submitter withdraws defect.
21329 <p><b>Proposed resolution:</b></p>
21331 Change 26.5.5 [rand.predef]/p5:
21335 <pre>typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12>
21339 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
21340 object of type <tt>ranlux48_base</tt> shall produce the value
21341 <del>61839128582725</del> <ins>192113843633948</ins>.
21350 <h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3>
21351 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21352 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
21353 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
21354 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21355 <p><b>Discussion:</b></p>
21357 The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be
21358 249142670248501. We get 88229545517833. (Note that this depends
21359 on <tt>ranlux48_base</tt>.)
21367 Submitter withdraws defect.
21372 <p><b>Proposed resolution:</b></p>
21374 Change 26.5.5 [rand.predef]/p6:
21378 <pre>typedef discard_block_engine<ranlux48_base, 389, 11>
21382 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
21383 object of type <tt>ranlux48</tt> shall produce the value
21384 <del>249142670248501</del> <ins>88229545517833</ins>.
21393 <h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3>
21394 <p><b>Section:</b> 26.5.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21395 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2010-10-29</p>
21396 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
21397 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21398 <p><b>Discussion:</b></p>
21400 TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt>
21401 returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>,
21402 consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely
21403 equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
21404 definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which
21405 will never be used to generate a random number. If two <tt>mersenne_twister</tt>s
21406 only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal,
21407 although they will produce an identical sequence of random numbers.
21411 26.5.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
21412 of <tt>operator==</tt> but uses a similar definition of the state and, just like
21413 TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
21414 <tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the
21415 lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the
21416 unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt>
21417 bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ,
21418 two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly
21419 implemented) but have different textual representations, which
21420 conceptually is a bit ugly.
21424 I propose that a paragraph or footnote is added to 26.5.3.2 [rand.eng.mers] which
21425 clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in
21426 <tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore
21427 the specification for the textual respresentation was changed to
21428 <tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ..., X<sub>i-1</sub></tt> or
21433 These changes would likely have no practical effect, but would allow an
21434 implementation that does the right thing to be standard-conformant.
21444 Fermi Lab has no objection to the proposed change. However it feels that
21445 more time is needed to check the details, which would suggest a change
21449 Bill feels that this is NAD, not enough practical importance to abandon
21450 the simple definition of equality, and someone would have to do a lot
21451 more study to ensure that all cases are covered for a very small
21452 payback. The submitter admits that "These changes would likely have no
21453 practical effect,", and according to Plum's razor this means that it is
21454 not worth the effort!
21457 Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
21462 <p><b>Proposed resolution:</b></p>
21464 In 26.5.3.2 [rand.eng.mers]:
21469 Insert at the end of para 2.:
21473 [<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence
21474 the state transition and hence should not be compared when comparing two
21475 <tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>]
21483 The textual representation of <tt>x<sub>i</sub></tt> consists of the values of
21484 <tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub></ins>,
21485 ..., X<sub>i-1</sub></tt>, in that order.
21494 <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
21495 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
21496 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2010-10-29</p>
21497 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
21498 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
21499 <p><b>Discussion:</b></p>
21501 The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
21502 defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
21503 Previous versions of this algorithm and the general logic behind it
21504 suggest that this is an oversight and that in the context of the
21505 for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
21506 upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
21507 in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
21512 There are two more minor issues:
21517 Strictly speaking <tt>end - begin</tt> is not defined since
21518 <tt>InputIterator</tt> is not required to be a random access iterator.
21521 Currently all integral types are allowed as input to the <tt>seed_seq</tt>
21522 constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
21523 complicates the implementation without any real benefit to the user.
21524 I'd suggest to exclude <tt>bool</tt>s as input.
21534 Move to OPEN Bill will try to propose a resolution by the next meeting.
21538 post Bellevue: Bill provided wording.
21543 This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> is accepted.
21548 <p><b>Proposed resolution:</b></p>
21550 Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
21555 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
21556 low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
21558 in ascending order of significance to make a (possibly very large) unsigned
21559 binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
21564 <blockquote><pre>for( v.clear(); n > 0; n -= 32 )
21565 v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
21566 </pre></blockquote>
21570 <p><b>Rationale:</b></p>
21572 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
21579 <h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
21580 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21581 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-20 <b>Last modified:</b> 2010-10-29</p>
21582 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
21583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21584 <p><b>Discussion:</b></p>
21586 The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
21587 1112339016. We get 2126698284.
21591 <p><b>Proposed resolution:</b></p>
21593 Change 26.5.5 [rand.predef]/p8:
21597 <pre>typedef shuffle_order_engine<minstd_rand0, 256>
21601 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
21602 object of type <tt>knuth_b</tt> shall produce the value
21603 <del>1112339016</del> <ins>2126698284</ins>.
21609 Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
21617 <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
21618 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
21619 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2008-02-22 <b>Last modified:</b> 2010-10-29</p>
21620 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
21621 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
21622 <p><b>Discussion:</b></p>
21624 <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
21625 object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
21629 This repacking triggers several problems:
21633 Distinctness of the output of <tt>seed_seq::generate</tt> required the
21634 introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise
21635 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
21638 Portability demanded the introduction of the template parameter <tt>u</tt>.
21639 (Otherwise some sequences could not be obtained on computers where no
21640 integer types are exactly 32-bits wide.)
21643 The description and algorithm have become unduly complicated.
21647 I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
21648 Despite it's being simpler, there is NO loss of functionality (see
21652 Here's how the description would read
21656 26.5.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
21660 <pre>template<class InputIterator>
21661 seed_seq(InputIterator begin, InputIterator end);
21665 5 <i>Requires:</i> NO CHANGE
21668 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
21671 <pre>for (InputIterator s = begin; s != end; ++s)
21672 v.push_back((*s) mod 2^32);
21683 The chief virtues here are simplicity, portability, and generality.
21687 Simplicity -- compare the above specification with the
21688 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
21691 Portability -- with <tt>iterator_traits<InputIterator>::value_type =
21692 uint_least32_t</tt> the user is guaranteed to get the same behavior across
21696 Generality -- any behavior that the
21697 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21698 proposal can achieve can be
21699 obtained with this simpler proposal (albeit with a shuffling of bits
21700 in the input sequence).
21704 Arguments (and counter-arguments) against making this change (and
21706 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21712 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
21716 Response: So what? Consider the seed string "ABC". The
21717 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21718 proposal results in
21720 <blockquote><pre>v = { 0x3, 0x434241 };
21721 </pre></blockquote>
21723 while the simplified proposal yields
21725 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
21726 </pre></blockquote>
21728 The results produced by <tt>seed_seq::generate</tt> with the two inputs are
21729 different but nevertheless equivalently "mixed up" and this remains
21730 true even if the seed string is long.
21735 With long strings (e.g., with bit-length comparable to the number of
21736 bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
21737 proposal and <tt>seed_seq::generate</tt> will be slower.
21740 Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
21741 be a big issue. If it is, the user is free to repack the seed vector
21742 before constructing <tt>seed_seq</tt>.
21747 A user can pass an array of 64-bit integers and all the bits will be
21751 Response: Indeed. However, there are many instances in the
21752 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21753 where integers are silently coerced to a narrower width and this
21754 should just be a case of the user needing to read the documentation.
21755 The user can of course get equivalent behavior by repacking his seed
21756 into 32-bit pieces. Furthermore, the unportability of the
21757 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21760 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
21761 seed_seq q(s, s+4);
21762 </pre></blockquote>
21764 which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
21765 <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
21766 unsuspecting users.
21772 Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.
21781 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
21791 Marc Paterno wants portable behavior between 32bit and 64bit machines;
21792 we've gone to significant trouble to support portability of engines and
21796 Jens: the new algorithm looks perfectly portable
21799 Marc Paterno to review off-line.
21802 Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
21805 Disposition: move to review; unanimous consent.
21808 (moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>)
21814 <p><b>Proposed resolution:</b></p>
21816 Change 26.5.7.1 [rand.util.seedseq]:
21820 <pre>template<class InputIterator<del>,
21821 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
21822 seed_seq(InputIterator begin, InputIterator end);
21826 -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
21827 such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type.
21830 -6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
21831 <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
21834 <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
21835 - begin</tt> elements of the supplied sequence and concatenate all the
21836 extracted bits to initialize a single (possibly very large) unsigned
21837 binary number, <tt>b = ∑<sup>n-1</sup><sub>i=0</sub> (begin[i]
21838 mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
21839 are treated as denoting an unsigned quantity). Then carry out
21840 the following algorithm:</del>
21842 <blockquote><pre><del>
21846 for( ; $n$ > 0; --$n$)
21847 v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
21848 </del></pre></blockquote>
21851 for (InputIterator s = begin; s != end; ++s)
21852 v.push_back((*s) mod 2<sup>32</sup>);
21859 <p><b>Rationale:</b></p>
21861 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
21868 <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
21869 <p><b>Section:</b> 25.4.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
21870 <b>Submitter:</b> Paul McKenney <b>Opened:</b> 2008-02-27 <b>Last modified:</b> 2010-10-29</p>
21871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
21872 <p><b>Discussion:</b></p>
21874 Multi-threading is a good thing, but unsolicited multi-threading can
21875 potentially be harmful. For example, <tt>sort()</tt> performance might be
21876 greatly increased via a multithreaded implementation. However, such
21877 a multithreaded implementation could result in concurrent invocations
21878 of the user-supplied comparator. This would in turn result in problems
21879 given a caching comparator that might be written for complex sort keys.
21880 Please note that this is not a theoretical issue, as multithreaded
21881 implementations of <tt>sort()</tt> already exist.
21884 Having a multithreaded <tt>sort()</tt> available is good, but it should not
21885 be the default for programs that are not explicitly multithreaded.
21886 Users should not be forced to deal with concurrency unless they have
21891 This may be covered by
21892 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
21893 Thread-Safety in the Standard Library (Rev 1).
21898 <p><b>Proposed resolution:</b></p>
21903 <p><b>Rationale:</b></p>
21904 This is already covered by 17.6.5.6/20 in N2723.
21911 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
21912 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21913 <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01 <b>Last modified:</b> 2010-11-29</p>
21914 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
21915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21916 <p><b>Discussion:</b></p>
21918 I just noticed that the following program is legal in C++03, but
21919 is forbidden in the current draft:
21922 <blockquote><pre>#include <vector>
21923 #include <iostream>
21929 explicit Toto( Toto const& ) {}
21935 std::vector< Toto > v( 10 ) ;
21938 </pre></blockquote>
21941 Is this change intentional? (And if so, what is the
21942 justification? I wouldn't call such code good, but I don't see
21943 any reason to break it unless we get something else in return.)
21952 The subgroup that looked at this felt this was a good change, but it may
21953 already be handled by incoming concepts (we're not sure).
21963 Alisdair: Proposed resolution kinda funky as these tables no longer
21964 exist. Move from direct init to copy init. Clarify with Doug, recommends
21968 Walter: Suggest NAD via introduction of concepts.
21971 Recommend close as NAD.
21981 Need to look at again without concepts.
21991 Move to Ready with original proposed resolution.
21993 <p><i>[Howard: Original proposed resolution restored.]</i></p>
22002 This issue was re-reviewed in relation to [another issue, number to follow],
22003 and the verdict was reversed. Explicit copy and move constructors are rare
22004 beasts, and the ripple effect of this fix was far more difficult to contain
22005 than simply saying such types do not satisfy the <tt>MoveConstructible</tt>
22006 and <tt>CopyConstructible</tt> requirements.
22011 In 20.2.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
22017 <th>expression</th><th>post-condition</th>
22020 <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
22023 <td colspan="2" align="center">...</td>
22029 In 20.2.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
22035 <th>expression</th><th>post-condition</th>
22038 <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
22041 <td colspan="2" align="center">...</td>
22050 <p><b>Proposed resolution:</b></p>
22051 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3215.html">n3215</a>.
22058 <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
22059 <p><b>Section:</b> 19.5.2.1 [syserr.errcode.overview], 20.9.10.2.8 [util.smartptr.shared.io], 22.4.8 [facets.examples], 20.5.4 [bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.9 [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
22060 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2010-10-29</p>
22061 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
22062 <p><b>Discussion:</b></p>
22063 <p><b>Addresses UK 220</b></p>
22066 Should the following use rvalues references to stream in insert/extract
22071 <li>19.5.2.1 [syserr.errcode.overview]</li>
22072 <li>20.9.10.2.8 [util.smartptr.shared.io]</li>
22073 <li>22.4.8 [facets.examples]</li>
22074 <li>20.5.4 [bitset.operators]</li>
22075 <li>26.4.6 [complex.ops]</li>
22076 <li>Doubled signatures in 27.6 [stream.buffers] for character inserters
22077 (ref 27.7.2.6.4 [ostream.inserters.character])
22078 + definition 27.7.2.6.4 [ostream.inserters.character]</li>
22079 <li>28.9 [re.submatch]</li>
22088 Agree with the idea in the issue, Alisdair to provide wording.
22092 Daniel adds 2009-02-14:
22097 The proposal given in the paper
22098 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html">N2831</a>
22099 apparently resolves this issue.
22108 The cited paper is an earlier version of
22109 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>,
22110 which changed the rvalue reference binding rules.
22111 That paper includes generic templates
22112 <tt>operator<<</tt> and <tt>operator>></tt>
22113 that adapt rvalue streams.
22116 We therefore agree with Daniel's observation.
22117 Move to NAD Editorial.
22122 <p><b>Proposed resolution:</b></p>
22131 <h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
22132 <p><b>Section:</b> 22.4.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
22133 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-07 <b>Last modified:</b> 2010-10-29</p>
22134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
22135 <p><b>Discussion:</b></p>
22137 In the spirit of <tt>printf vs iostream</tt>...
22141 POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
22142 implication is that in the absence of <tt>'</tt> no grouping characters are
22143 inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
22144 grouping characters. Can this be considered a defect worth fixing for
22145 C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
22154 I'm not sure it constitutes a defect, but I would be in favor of adding
22155 another flag (and corresponding manipulator).
22164 I don't know if it qualifies as a defect but I agree that there
22165 should be an easy way to control whether the thousands separator
22166 should or shouldn't be inserted. A new flag would be in line with
22167 the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
22168 <tt>showbase</tt>).
22177 This is not a part of C99. LWG suggests submitting a paper may be appropriate.
22182 <p><b>Proposed resolution:</b></p>
22191 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
22192 <p><b>Section:</b> 30.4.1.2.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
22193 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18 <b>Last modified:</b> 2010-10-29</p>
22194 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
22195 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
22196 <p><b>Discussion:</b></p>
22198 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
22201 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
22202 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
22203 we should strive to eliminate such regressions in expressive power where
22204 possible, both to ease migration and to not provide incentives to (or
22205 force) people to forego the C++ primitives in favor of pthreads.
22215 We believe this is implementable on POSIX, because the initializer-list
22216 feature and the constexpr feature make this work. Double-check core
22217 language about static initialization for this case. Ask core for a core
22218 issue about order of destruction of statically-initialized objects wrt.
22219 dynamically-initialized objects (should come afterwards). Check
22220 non-POSIX systems for implementability.
22223 If ubiquitous implementability cannot be assured, plan B is to introduce
22224 another constructor, make this constexpr, which is
22225 conditionally-supported. To avoid ambiguities, this new constructor needs
22226 to have an additional parameter.
22237 Jens: constant initialization seems to be ok core-language wise
22240 Consensus: Defer to threading experts, in particular a Microsoft platform expert.
22243 Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
22244 Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
22245 Peter Dimov to alert them of this issue.
22248 Lawrence: What about header file shared with C? The initialization
22249 syntax is different in C and C++.
22252 Recommend Keep in Review
22261 Keep in Review status pending feedback from members of the Concurrency subgroup.
22265 See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>.
22270 2009-10 Santa Cruz:
22275 NAD Editorial. Solved by
22276 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
22281 <p><b>Proposed resolution:</b></p>
22283 Change 30.4.1.2.1 [thread.mutex.class]:
22286 <blockquote><pre>class mutex {
22288 <ins>constexpr</ins> mutex();
22290 </pre></blockquote>
22297 <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
22298 <p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
22299 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2010-10-29</p>
22300 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
22301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
22302 <p><b>Discussion:</b></p>
22304 Paragraph 4 of 21.2 [char.traits] mentions that this
22305 section specifies two specializations (<code>char_traits<char></code>
22306 and (<code>char_traits<wchar_t></code>). However, there are actually
22307 four specializations provided, i.e. in addition to the two above also
22308 <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
22309 I guess this was just an oversight and there is nothing wrong with just
22318 <tt>char_traits< char16/32_t ></tt>
22319 should also be added to <tt><ios_fwd></tt> in 27.3 [iostream.forward], and all the specializations
22320 taking a <tt>char_traits</tt> parameter in that header.
22330 Idea of the issue is ok.
22333 Alisdair to provide wording, once that wording arrives, move to review.
22339 2009-05-04 Alisdair adds:
22345 The main point of the issue was resolved editorially in
22346 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
22348 close to NAD Editorial.
22349 However, exploring the issue we found a second tweak was necessary for
22350 <tt><iosfwd></tt> and that is still outstanding, so here are the words I am long
22351 overdue delivering:
22355 Howard: I've put Alisdair's words into the proposed wording section and
22356 moved the issue to Review.
22363 Original proposed wording.
22370 Replace paragraph 4 of 21.2 [char.traits] by:
22374 This subclause specifies a struct template, <code>char_traits<charT></code>,
22375 and four explicit specializations of it, <code>char_traits<char></code>,
22376 <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
22377 <code>char_traits<wchar_t></code>, all of which appear in the header
22378 <string> and satisfy the requirements below.
22388 We agree. Move to NAD Editorial.
22392 <p><b>Proposed resolution:</b></p>
22394 Change Forward declarations 27.3 [iostream.forward]:
22399 <b>Header <tt><iosfwd></tt> synopsis</b>
22401 <pre>namespace std {
22402 template<class charT> class char_traits;
22403 template<> class char_traits<char>;
22404 <ins>template<> class char_traits<char16_t>;</ins>
22405 <ins>template<> class char_traits<char32_t>;</ins>
22406 template<> class char_traits<wchar_t>;
22417 <h3><a name="831"></a>831. wrong type for not_eof()</h3>
22418 <p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
22419 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2010-10-29</p>
22420 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
22421 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
22422 <p><b>Discussion:</b></p>
22424 In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
22425 is using an argument of type <i>e</i> which denotes an object of
22426 type <code>X::int_type</code>. However, the specializations in
22427 21.2.3 [char.traits.specializations] all use <code>char_type</code>.
22428 This would effectively mean that the argument type actually can't
22429 represent EOF in the first place. I'm pretty sure that the type used
22430 to be <code>int_type</code> which is quite obviously the only sensible
22434 This issue is close to being editorial. I suspect that the proposal
22435 changing this section to include the specializations for <code>char16_t</code>
22436 and <code>char32_t</code> accidentally used the wrong type.
22440 <p><b>Proposed resolution:</b></p>
22442 In 21.2.3.1 [char.traits.specializations.char],
22443 21.2.3.2 [char.traits.specializations.char16_t],
22444 21.2.3.3 [char.traits.specializations.char32_t], and
22445 [char.traits.specializations.wchar_t] correct the
22446 argument type from <code>char_type</code> to <code>int_type</code>.
22450 <p><b>Rationale:</b></p>
22451 Already fixed in WP.
22458 <h3><a name="832"></a>832. Applying constexpr to System error support</h3>
22459 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
22460 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2010-10-29</p>
22461 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
22462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
22463 <p><b>Discussion:</b></p>
22465 Initialization of objects of class <tt>error_code</tt>
22466 (19.5.2 [syserr.errcode]) and class
22467 <tt>error_condition</tt> (19.5.3 [syserr.errcondition]) can be made simpler and more reliable by use of
22468 the new <tt>constexpr</tt> feature
22469 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
22470 of C++0x. Less code will need to be
22471 generated for both library implementations and user programs when
22472 manipulating constant objects of these types.
22476 This was not proposed originally because the constant expressions
22477 proposal was moving into the standard at about the same time as the
22478 Diagnostics Enhancements proposal
22479 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
22480 and it wasn't desirable to
22481 make the later depend on the former. There were also technical concerns
22482 as to how <tt>constexpr</tt> would apply to references. Those concerns are now
22483 resolved; <tt>constexpr</tt> can't be used for references, and that fact is
22484 reflected in the proposed resolution.
22488 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
22492 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> is related in that it raises the question of whether the
22493 exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.5.2 [syserr.errcode]) and class
22494 <tt>error_condition</tt> (19.5.3 [syserr.errcondition]) should be presented as a reference or pointer.
22495 While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> that is arguably an editorial question,
22496 presenting it as a pointer becomes more or less required with this
22497 proposal, given <tt>constexpr</tt> does not play well with references. The
22498 proposed resolution thus changes the private member to a pointer, which
22499 also brings it in sync with real implementations.
22508 On going question of extern pointer vs. inline functions for interface.
22518 Beman Dawes reports that this proposal is unimplementable, and thus NAD.
22521 Implementation would require <tt>constexpr</tt> objects of classes derived
22522 from class <tt>error_category</tt>, which has virtual functions, and that is
22523 not allowed by the core language. This was determined when trying to
22524 implement the proposal using a constexpr enabled compiler provided
22525 by Gabriel Dos Reis, and subsequently verified in discussions with
22526 Gabriel and Jens Maurer.
22532 <p><b>Proposed resolution:</b></p>
22534 The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> proposed wording has been
22535 applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
22536 <tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has not been applied, the names in this
22537 proposal must be adjusted accordingly.
22541 Change 19.5.1.1 [syserr.errcat.overview] Class
22542 <tt>error_category</tt> overview <tt>error_category</tt> synopsis as
22546 <blockquote><pre><del>const error_category& get_generic_category();</del>
22547 <del>const error_category& get_system_category();</del>
22549 <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
22550 <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
22551 </pre></blockquote>
22554 Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
22558 <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
22561 <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
22562 to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
22563 class <tt>error_category</tt>.
22567 <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
22568 functions shall behave as specified for the class <tt>error_category</tt>. The
22569 object's <tt>name</tt> virtual function shall return a pointer to the string
22570 <tt>"GENERIC"</tt>.
22573 <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
22577 <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
22578 to <del>an</del> <ins>a statically
22579 initialized</ins> object of a type derived from class <tt>error_category</tt>.
22583 <del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
22584 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
22585 shall return a pointer to the string <tt>"system"</tt>. The object's
22586 <tt>default_error_condition</tt> virtual function shall behave as follows:
22590 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
22591 shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
22592 function shall return <tt>error_condition(ev, system_category)</tt>. What
22593 constitutes correspondence for any given operating system is
22594 unspecified. [<i>Note:</i> The number of potential system error codes is large
22595 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
22596 Thus implementations are given latitude in determining correspondence.
22597 <i>-- end note</i>]
22602 Change 19.5.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
22605 <blockquote><pre>class error_code {
22608 <ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
22610 void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
22612 const error_category<del>&</del><ins>*</ins> category() const;
22615 int val_; // exposition only
22616 const error_category<del>&</del><ins>*</ins> cat_; // exposition only
22617 </pre></blockquote>
22620 Change 19.5.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
22624 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
22627 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
22630 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22633 <i>Throws:</i> Nothing.
22638 Change 19.5.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
22642 <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
22645 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22648 <i>Throws:</i> Nothing.
22653 Change 19.5.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated:
22657 <pre>const error_category<del>&</del><ins>*</ins> category() const;
22661 <i>Returns:</i> <tt>cat_</tt>.
22664 <i>Throws:</i> Nothing.
22669 Change 19.5.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated:
22673 <pre>class error_condition {
22676 <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
22678 void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
22680 const error_category<del>&</del><ins>*</ins> category() const;
22683 int val_; // exposition only
22684 const error_category<del>&</del><ins>*</ins> cat_; // exposition only
22689 Change 19.5.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
22693 <pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
22696 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
22699 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22702 <i>Throws:</i> Nothing.
22707 Change 19.5.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
22711 <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
22714 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22717 <i>Throws:</i> Nothing.
22722 Change 19.5.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
22726 <pre>const error_category<del>&</del><ins>*</ins> category() const;
22729 <i>Returns:</i> <tt>cat_</tt>.
22732 <i>Throws:</i> Nothing.
22737 Throughout 19.5 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>".
22738 Appears approximately six times.
22742 <i>[Partially Editorial]</i> In 19.5.4 [syserr.compare] Comparison operators,
22743 paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
22744 "<tt>category()->equivalent(</tt>".
22748 Change 19.5.6.1 [syserr.syserr.overview] Class system_error overview as indicated:
22751 <blockquote><pre>public:
22752 system_error(error_code ec, const string& what_arg);
22753 system_error(error_code ec);
22754 system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat,
22755 const string& what_arg);
22756 system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
22757 </pre></blockquote>
22760 Change 19.5.6.2 [syserr.syserr.members] Class system_error members as indicated:
22764 <pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg);
22768 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22771 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22772 <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
22776 <pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
22780 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22783 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22784 <tt>strcmp(runtime_error::what(), "") == 0</tt>.
22791 <p><b>Rationale:</b></p>
22798 NAD because Beman said so.
22806 <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
22807 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
22808 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2010-10-29</p>
22809 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
22810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
22811 <p><b>Discussion:</b></p>
22813 Once the C++0x standard library is feature complete, the LWG needs to
22814 review 17.6.1.3 [compliance] Freestanding implementations header list to
22815 ensure it reflects LWG consensus.
22825 This is a placeholder defect to remind us to review the table once we've
22826 stopped adding headers to the library.
22829 Three new headers that need to be added to the list:
22831 <blockquote><pre><initializer_list> <concept> <iterator_concepts>
22832 </pre></blockquote>
22834 <tt><iterator_concepts></tt>, in particular, has lots of stuff
22835 that isn't needed, so maybe the stuff that is needed should be broken
22836 out into a separate header.
22839 Robert: What about <tt>reference_closure</tt>? It's currently in
22840 <tt><functional></tt>.
22845 Post Summit Daniel adds:
22852 The comment regarding <tt>reference_closure</tt> seems moot since it was just
22853 recently decided to remove that.
22856 A reference to proposal
22857 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>
22858 ("Fixing freestanding") should be added. This
22859 paper e.g. proposes to add only <tt><initializer_list></tt> to the include list
22873 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>.
22882 <p><b>Proposed resolution:</b></p>
22889 <h3><a name="837"></a>837.
22890 <code>basic_ios::copyfmt()</code> overly loosely specified
22892 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
22893 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
22894 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
22895 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
22896 <p><b>Discussion:</b></p>
22899 The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:
22904 <i>Effects</i>: If <code>(this == &rhs)</code> does
22905 nothing. Otherwise assigns to the member objects of <code>*this</code>
22906 the corresponding member objects of <code>rhs</code>, except that
22911 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
22916 <code>exceptions()</code> is altered last by
22917 calling <code>exceptions(rhs.except)</code>
22922 the contents of arrays pointed at by <code>pword</code>
22923 and <code>iword</code> are copied not the pointers themselves
22930 Since the rest of the text doesn't specify what the member objects
22931 of <code>basic_ios</code> are this seems a little too loose.
22940 We agree with the proposed resolution.
22941 Move to NAD Editorial.
22945 <p><b>Proposed resolution:</b></p>
22948 I propose to tighten things up by adding a <i>Postcondition</i> clause
22949 to the function like so:
22953 <i>Postconditions:</i>
22958 <th colspan="2"><code>copyfmt()</code> postconditions</th>
22967 <td><code>rdbuf()</code></td>
22968 <td><i>unchanged</i></td>
22971 <td><code>tie()</code></td>
22972 <td><code>rhs.tie()</code></td>
22975 <td><code>rdstate()</code></td>
22976 <td><i>unchanged</i></td>
22979 <td><code>exceptions()</code></td>
22980 <td><code>rhs.exceptions()</code></td>
22983 <td><code>flags()</code></td>
22984 <td><code>rhs.flags()</code></td>
22987 <td><code>width()</code></td>
22988 <td><code>rhs.width()</code></td>
22991 <td><code>precision()</code></td>
22992 <td><code>rhs.precision()</code></td>
22995 <td><code>fill()</code></td>
22996 <td><code>rhs.fill()</code></td>
22999 <td><code>getloc()</code></td>
23000 <td><code>rhs.getloc()</code></td>
23007 The format of the table follows Table 117 (as
23008 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
23014 The intent of the new table is not to impose any new requirements or
23015 change existing ones, just to be more explicit about what I believe is
23024 <h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
23025 <p><b>Section:</b> 23.6 [associative], 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
23026 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2008-05-18 <b>Last modified:</b> 2010-10-29</p>
23027 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
23028 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
23029 <p><b>Discussion:</b></p>
23031 Splice is a very useful feature of <tt>list</tt>. This functionality is also very
23032 useful for any other node based container, and I frequently wish it were
23033 available for maps and sets. It seems like an omission that these
23034 containers lack this capability. Although the complexity for a splice is
23035 the same as for an insert, the actual time can be much less since the
23036 objects need not be reallocated and copied. When the element objects are
23037 heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
23038 this can be a big win.
23042 <b>Suggested resolution:</b>
23046 Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
23049 void splice(list<T,Allocator>&& x);
23050 void splice(list<T,Allocator>&& x, const_iterator i);
23051 void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
23052 </pre></blockquote>
23055 Hint versions of these are also useful to the extent hint is useful.
23056 (I'm looking for guidance about whether hints are in fact useful.)
23060 void splice(const_iterator position, list<T,Allocator>&& x);
23061 void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
23062 void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
23063 </pre></blockquote>
23072 Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
23075 <tt>forward_list</tt> already has <tt>splice_after</tt>.
23078 Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
23081 Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
23084 Howard: <tt>adopt</tt>?
23087 Jens: <tt>absorb</tt>?
23090 Alan: <tt>subsume</tt>?
23093 Robert: <tt>recycle</tt>?
23096 Howard: <tt>transfer</tt>? (but no direction)
23099 Jens: <tt>transfer_from</tt>. No.
23102 Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
23105 Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
23116 Martin: this would possibly outlaw an implementation technique that is
23117 currently in use; caching nodes in containers.
23120 Alan: if you cache in the allocator, rather than the individual
23121 container, this proposal doesn't interfere with that.
23124 Martin: I'm not opposed to this, but I'd like to see an implementation
23125 that demonstrates that it works.
23139 2009-09-19 Howard adds:
23145 I'm not disagreeing with the NAD Future resolution. But when the future gets
23146 here, here is a possibility worth exploring:
23151 Add to the "unique" associative containers:
23154 <blockquote><pre>typedef <i>details</i> node_ptr;
23156 node_ptr remove(const_iterator p);
23157 pair<iterator, bool> insert(node_ptr&& nd);
23158 iterator insert(const_iterator p, node_ptr&& nd);
23159 </pre></blockquote>
23162 And add to the "multi" associative containers:
23165 <blockquote><pre>typedef <i>details</i> node_ptr;
23167 node_ptr remove(const_iterator p);
23168 iterator insert(node_ptr&& nd);
23169 iterator insert(const_iterator p, node_ptr&& nd);
23170 </pre></blockquote>
23173 <tt>Container::node_ptr</tt> is a smart pointer much like <tt>unique_ptr</tt>.
23174 It owns a node obtained from the container it was removed from. It maintains a
23175 reference to the allocator in the container so that it can properly deallocate
23176 the node if asked to, even if the allocator is stateful. This being said, the
23177 <tt>node_ptr</tt> can not outlive the container for this reason.
23181 The <tt>node_ptr</tt> offers "<tt>const</tt>-free" access to the node's
23182 <tt>value_type</tt>.
23186 With this interface, clients have a great deal of flexibility:
23191 A client can remove a node from one container, and insert it into another
23192 (without any heap allocation). This is the splice functionality this issue
23196 A client can remove a node from a container, change its key or value, and insert
23197 it back into the same container, or another container, all without the cost of
23201 If the Compare function is nothrow (which is very common), then this functionality
23202 is nothrow unless modifying the value throws. And if this does throw, it does
23203 so outside of the containers involved.
23206 If the Compare function does throw, the <tt>insert</tt> function will have the
23207 argument <tt>nd</tt> retain ownership of the node.
23210 The <tt>node_ptr</tt> should be independent of the <tt>Compare</tt> parameter
23211 so that a node can be transferred from <tt>set<T, C1, A></tt>
23212 to <tt>set<T, C2, A></tt> (for example).
23217 Here is how the customer might use this functionality:
23223 Splice a node from one container to another:
23225 <blockquote><pre>m2.insert(m1.remove(i));
23226 </pre></blockquote>
23231 Change the "key" in a <tt>std::map</tt> without the cost of node reallocation:
23233 <blockquote><pre>auto p = m.remove(i);
23234 p->first = new_key;
23235 m.insert(std::move(p));
23236 </pre></blockquote>
23241 Change the "value" in a <tt>std::set</tt> without the cost of node reallocation:
23243 <blockquote><pre>auto p = s.remove(i);
23245 s.insert(std::move(p));
23246 </pre></blockquote>
23251 Move a move-only or heavy object out of an associative container (as opposed to
23252 the proposal in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>):
23254 <blockquote><pre>MoveOnly x = std::move(*s.remove(i));
23255 </pre></blockquote>
23258 <tt>remove(i)</tt> transfers ownership of the node from the set to a temporary
23262 The <tt>node_ptr</tt> is dereferenced, and that non-const reference is sent to
23263 <tt>move</tt> to cast it to an rvalue.
23266 The rvalue <tt>MoveOnly</tt> is move constructed into <tt>x</tt> from
23267 the <tt>node_ptr</tt>.
23270 <tt>~node_ptr()</tt> destructs the moved-from <tt>MoveOnly</tt> and deallocates
23276 Contrast this with the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a> solution:
23278 <blockquote><pre>MoveOnly x = std::move(s.extract(i).first);
23279 </pre></blockquote>
23282 The former requires one move construction for <tt>x</tt> while the latter
23283 requires two (one into the <tt>pair</tt> and then one into <tt>x</tt>). Either
23284 of these constructions can throw (say if there is only a copy constructor for
23285 <tt>x</tt>). With the former, the point of throw is outside of the container
23286 <tt>s</tt>, after the element has been removed from the container. With the latter,
23287 one throwing construction takes place prior to the removal of the element, and
23288 the second takes place after the element is removed.
23295 The "node insertion" API maintains the API associated with inserting <tt>value_type</tt>s
23296 so the customer can use familiar techniques for getting an iterator to the
23297 inserted node, or finding out whether it was inserted or not for the "unique"
23302 Lightly prototyped. No implementation problems. Appears to work great
23311 <p><b>Proposed resolution:</b></p>
23318 <h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
23319 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
23320 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-05-23 <b>Last modified:</b> 2010-10-29</p>
23321 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
23322 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
23323 <p><b>Discussion:</b></p>
23325 I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
23326 historical accident, but why is there no default template argument for
23327 the second template argument? This is so annoying when the type in
23328 question is looong and hard to write (type deduction with <tt>auto</tt> won't
23329 help those cases where we use it as a return or argument type).
23333 <p><b>Proposed resolution:</b></p>
23335 Change the synopsis in 20.3 [utility] to read:
23338 <blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair;
23339 </pre></blockquote>
23342 Change 20.3.5 [pairs] to read:
23345 <blockquote><pre>namespace std {
23346 template <class T1, class T2 <ins>= T1</ins>>
23348 typedef T1 first_type;
23349 typedef T2 second_type;
23351 </pre></blockquote>
23354 <p><b>Rationale:</b></p>
23355 <tt>std::pair</tt> is a heterogeneous container.
23362 <h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
23363 <p><b>Section:</b> 18.4.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
23364 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
23365 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
23366 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
23367 <p><b>Discussion:</b></p>
23370 In specifying the names of macros and types defined in
23371 header <code><stdint.h></code>, C99 makes use of the
23372 symbol <code><i>N</i></code> to accommodate unusual platforms with
23373 word sizes that aren't powers of two. C99
23374 permits <code><i>N</i></code> to take on any positive integer value
23375 (including, for example, 24).
23380 In cstdint.syn Header <code><cstdint></code>
23381 synopsis, C++ on the other hand, fixes the value
23382 of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
23383 types with these exact widths.
23389 In addition, paragraph 1 of the same section makes use of a rather
23390 informal shorthand notation to specify sets of macros. When
23391 interpreted strictly, the notation specifies macros such
23392 as <code>INT_8_MIN</code> that are not intended to be specified.
23396 Finally, the section is missing the usual table of symbols defined
23397 in that header, making it inconsistent with the rest of the
23402 <p><b>Proposed resolution:</b></p>
23405 I propose to use the same approach in the C++ spec as C99 uses, that
23406 is, to specify the header synopsis in terms of "exposition only" types
23407 that make use of the symbol <code><i>N</i></code> to denote one or
23408 more of a theoretically unbounded set of widths.
23413 Further, I propose to add a new table to section listing the symbols
23414 defined in the header using a more formal notation that avoids
23415 introducing inconsistencies.
23420 To this effect, in cstdint.syn
23421 Header <code><cstdint></code> synopsis, replace both the
23422 synopsis and paragraph 1 with the following text:
23430 In the names defined in the <code><cstdint></code> header, the
23431 symbol <code><i>N</i></code> represents a positive decimal integer
23432 with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
23433 exception of exact-width types, macros and types for values
23434 of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
23435 required. Exact-width types, and any macros and types for values
23436 of <code><i>N</i></code> other than 8, 16, 32, and 64 are
23437 optional. However, if an implementation provides integer types with
23438 widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
23439 and macros are required.
23444 <pre>namespace std {
23448 // Fastest minimum-width integer types
23449 typedef <i>signed integer type</i> int_fast8_t;
23450 typedef <i>signed integer type</i> int_fast16_t;
23451 typedef <i>signed integer type</i> int_fast32_t;
23452 typedef <i>signed integer type</i> int_fast64_t;
23454 typedef <i>unsigned integer type</i> uint_fast8_t;
23455 typedef <i>unsigned integer type</i> uint_fast16_t;
23456 typedef <i>unsigned integer type</i> uint_fast32_t;
23457 typedef <i>unsigned integer type</i> uint_fast64_t;
23459 // Minimum-width integer types
23460 typedef <i>signed integer type</i> int_least8_t;
23461 typedef <i>signed integer type</i> int_least16_t;
23462 typedef <i>signed integer type</i> int_least32_t;
23463 typedef <i>signed integer type</i> int_least64_t;
23465 typedef <i>unsigned integer type</i> uint_least8_t;
23466 typedef <i>unsigned integer type</i> uint_least16_t;
23467 typedef <i>unsigned integer type</i> uint_least32_t;
23468 typedef <i>unsigned integer type</i> uint_least64_t;
23470 // Greatest-width integer types
23471 typedef <i>signed integer type</i> intmax_t;
23472 typedef <i>unsigned integer type</i> uintmax_t;
23474 // optionally defined types
23476 // Exact-width integer types
23477 typedef <i>signed integer type</i> int<i>N</i>_t;
23478 typedef <i>unsigned integer type</i> uint<i>N</i>_t;
23480 // Fastest minimum-width integer types for values
23481 // of <i>N</i> other than 8, 16, 32, and 64
23482 typedef <i>signed integer type</i> uint_fast<i>N</i>_t;
23483 typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
23485 // Minimum-width integer types for values
23486 // of <i>N</i> other than 8, 16, 32, and 64
23487 typedef <i>signed integer type</i> uint_least<i>N</i>_t;
23488 typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
23490 // Integer types capable of holding object pointers
23491 typedef <i>signed integer type</i> intptr_t;
23492 typedef <i>signed integer type</i> intptr_t;
23498 [Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.]
23502 Table ??: Header <code><cstdint></code> synopsis
23507 <th colspan="3">Name(s)</th>
23512 <td rowspan="11"><b>Macros:</b></td>
23513 <td><tt>INT<i>N</i>_MIN</tt></td>
23514 <td><tt>INT<i>N</i>_MAX</tt></td>
23515 <td><tt>UINT<i>N</i>_MAX</tt></td>
23518 <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
23519 <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
23520 <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
23523 <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
23524 <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
23525 <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
23528 <td><tt>INTPTR_MIN</tt></td>
23529 <td><tt>INTPTR_MAX</tt></td>
23530 <td><tt>UINTPTR_MAX</tt></td>
23533 <td><tt>INTMAX_MIN</tt></td>
23534 <td><tt>INTMAX_MAX</tt></td>
23535 <td><tt>UINTMAX_MAX</tt></td>
23538 <td><tt>PTRDIFF_MIN</tt></td>
23539 <td><tt>PTRDIFF_MAX</tt></td>
23540 <td><tt>PTRDIFF_MAX</tt></td>
23543 <td><tt>SIG_ATOMIC_MIN</tt></td>
23544 <td><tt>SIG_ATOMIC_MAX</tt></td>
23545 <td><tt>SIZE_MAX</tt></td>
23548 <td><tt>WCHAR_MIN</tt></td>
23549 <td><tt>WCHAR_MAX</tt></td>
23553 <td><tt>WINT_MIN</tt></td>
23554 <td><tt>WINT_MAX</tt></td>
23558 <td><tt>INT<i>N</i>_C()</tt></td>
23559 <td><tt>UINT<i>N</i>_C()</tt></td>
23563 <td><tt>INTMAX_C()</tt></td>
23564 <td><tt>UINTMAX_C()</tt></td>
23568 <td rowspan="5"><b>Types:</b></td>
23569 <td><tt>int<i>N</i>_t</tt></td>
23570 <td><tt>uint<i>N</i>_t</tt></td>
23574 <td><tt>int_fast<i>N</i>_t</tt></td>
23575 <td><tt>uint_fast<i>N</i>_t</tt></td>
23579 <td><tt>int_least<i>N</i>_t</tt></td>
23580 <td><tt>uint_least<i>N</i>_t</tt></td>
23584 <td><tt>intptr_t</tt></td>
23585 <td><tt>uintptr_t</tt></td>
23589 <td><tt>intmax_t</tt></td>
23590 <td><tt>uintmax_t</tt></td>
23602 <h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
23603 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
23604 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
23605 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
23606 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
23607 <p><b>Discussion:</b></p>
23609 The type traits library contains various traits to dealt with
23610 polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
23611 and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
23612 public base class of a type if such one exists. Such a trait could be
23613 very useful if one needs to instantiate a specialization made for the
23614 root class whenever a derived class is passed as parameter. For example,
23615 imagine that you wanted to specialize <tt>std::hash</tt> for a class
23616 hierarchy---instead of specializing each class, you could specialize the
23617 <tt>std::hash<root_class></tt> and provide a partial specialization that worked
23618 for all derived classes.
23622 This ability---to specify operations in terms of their equivalent in the
23623 root class---can be done with e.g. normal functions, but there is,
23624 AFAIK, no way to do it for class templates. Being able to access
23625 compile-time information about the type-hierachy can be very powerful,
23626 and I therefore also suggest traits that computes the directly derived
23627 class whenever that is possible.
23631 If the computation can not be done, the traits should fall back on an
23632 identity transformation. I expect this gives the best overall usability.
23636 <p><b>Proposed resolution:</b></p>
23638 Add the following to the synopsis in 20.7.2 [meta.type.synop] under "other transformations":
23641 <blockquote><pre>template< class T > struct direct_base_class;
23642 template< class T > struct direct_derived_class;
23643 template< class T > struct root_base_class;
23644 </pre></blockquote>
23647 Add three new entries to table 51 (20.7.7.6 [meta.trans.other]) with the following content
23653 <th>Template</th><th>Condition</th><th>Comments</th>
23656 <td><tt>template< class T > struct direct_base_class;</tt></td>
23657 <td><tt>T</tt> shall be a complete type.</td>
23658 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
23659 If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
23662 <td><tt>template< class T > struct direct_derived_class;</tt></td>
23663 <td><tt>T</tt> shall be a complete type.</td>
23664 <td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
23665 as an accessible unambiguous direct base class. If no such type exists, the member typedef
23666 <tt>type</tt> shall equal <tt>T</tt>.</td>
23669 <td><tt>template< class T > struct root_base_class;</tt></td>
23670 <td><tt>T</tt> shall be a complete type.</td>
23671 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
23672 <tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
23679 <p><b>Rationale:</b></p>
23680 2008-9-16 San Francisco: Issue pulled by author prior to being reviewed by the LWG.
23687 <h3><a name="851"></a>851. simplified array construction</h3>
23688 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
23689 <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
23690 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
23691 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
23692 <p><b>Discussion:</b></p>
23694 This is an issue that came up on the libstdc++ list, where a
23695 discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
23700 In "C," this array usage is possible:
23703 <blockquote><pre>int ar[] = {1, 4, 6};
23704 </pre></blockquote>
23710 <blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error
23711 </pre></blockquote>
23714 Instead, the second parameter of the <tt>array</tt> template must be
23718 <blockquote><pre>std::array<int, 3> a = { 1, 4, 6 };
23719 </pre></blockquote>
23722 Doug Gregor proposes the following solution, that assumes
23723 generalized initializer lists.
23726 <blockquote><pre>template<typename T, typename... Args>
23727 inline array<T, sizeof...(Args)>
23728 make_array(Args&&... args)
23729 { return { std::forward<Args>(args)... }; }
23730 </pre></blockquote>
23733 Then, the way to build an <tt>array</tt> from a list of unknown size is:
23736 <blockquote><pre>auto a = make_array<T>(1, 4, 6);
23737 </pre></blockquote>
23746 Benjamin: Move to Ready?
23749 Bjarne: I'm not convinced this is useful enough to add, so I'd like us
23750 to have time to reflect on it.
23753 Alisdair: the constraints are wrong, they should be
23755 <blockquote><pre>template<ValueType T, ValueType... Args>
23756 requires Convertible<Args, T>...
23757 array<T, sizeof...(Args)> make_array(Args&&... args);
23758 </pre></blockquote>
23760 Alidair: this would be useful if we had a constexpr version.
23763 Bjarne: this is probably useful for arrays with a small number of
23764 elements, but it's not clearly useful otherwise.
23767 Consensus is to move to Open.
23772 2009-06-07 Daniel adds:
23778 I suggest a fix and a simplification of the current proposal: Recent
23780 Howard showed, that a fix is required because narrowing conversion
23781 8.5.4 [dcl.init.list]/6 b.3
23782 would severely limit the possible distribution of argument types, e.g.
23784 <tt>make_array<double>(1, 2.0)</tt> is ill-formed, because the narrowing
23785 happens <em>inside</em> the
23786 function body where no constant expressions exist anymore. Furthermore
23789 <blockquote><pre>int f();
23791 </pre></blockquote>
23793 we probably want to support
23795 <blockquote><pre>make_array<double>(f(), g());
23796 </pre></blockquote>
23799 as well. To make this feasible, the currently suggested expansion
23802 <blockquote><pre>{ std::forward<Args>(args)... }
23803 </pre></blockquote>
23806 needs to be replaced by
23809 <blockquote><pre>{ static_cast<T>(std::forward<Args>(args))... }
23810 </pre></blockquote>
23813 which is safe, because we already ensure convertibility via the
23814 element-wise <tt>Convertible<Args, T></tt> requirement. Some other fixes are
23815 necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
23816 is invalid, because all lvalue arguments will deduce to an lvalue-reference,
23817 thereby no longer satisfying this requirement.
23821 The suggested simplification is to provide a default-computed effective
23822 type for the result array based on common_type and decay, in
23823 unconstrained form:
23826 <blockquote><pre>template<typename... Args>
23827 array<typename decay<typename common_type<Args...>::type>::type,
23828 sizeof...(Args)>
23829 make_array(Args&&... args);
23830 </pre></blockquote>
23833 The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
23834 using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
23835 handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
23836 our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
23837 an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
23838 <tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
23839 add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
23840 need something like this to succeed. Note that we use a similar fuzziness for
23841 <tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
23843 missing <tt>Constructible<Vi, Ti&&></tt> requirement for those functions. The following
23844 proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
23846 explicitly wanted for standardization, here the implementation
23849 <blockquote><pre>auto concept DC<typename... T> {
23850 typename type = typename decay<typename common_type<T...>::type>::type;
23852 </pre></blockquote>
23855 where <tt>C</tt> is identical to <tt>DC<Args...>::type</tt> in the proposed resolution below.
23858 I intentionally added no further type relation between type and the concept
23859 template parameters, but instead added this requirement below to make
23860 the specification as transparent as possible. As written this concept is
23861 satisfied, if the corresponding associated type exists.
23864 <p><b>Suggested Resolution:</b></p>
23869 Add to the array synopsis in 23.3 [sequences]:
23871 <blockquote><pre><ins>
23872 template<ReferentType... Args>
23873 requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...
23874 array<C, sizeof...(Args)>
23875 make_array(Args&&... args);
23877 </pre></blockquote>
23882 Append after 23.3.1.8 [array.tuple] Tuple interface to class template array
23883 the following new section:
23887 23.4.1.7 Array creation functions [array.creation]
23891 template<ReferentType... Args>
23892 requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...
23893 array<C, sizeof...(Args)>
23894 make_array(Args&&... args);</ins>
23899 Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>.
23902 <ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with
23903 <tt>{ static_cast<C>(std::forward<Args>(args))... }</tt>.
23921 The proposed resolution uses concepts.
23924 Daniel to rewrite the proposed resolution.
23932 2009-07-25 Daniel provides rewritten proposed resolution.
23937 2009-10 Santa Cruz:
23942 Argument for NAD future: everything about this could be added on. This
23943 does not require changes to the existing text.
23948 <p><b>Proposed resolution:</b></p>
23953 Add to the array synopsis in 23.3 [sequences]:
23956 <blockquote><pre><ins>template<class... Args>
23957 array<<i>CT</i>, sizeof...(Args)>
23958 make_array(Args&&... args);</ins>
23959 </pre></blockquote>
23964 Append after 23.3.1.8 [array.tuple] "Tuple interface to class template array" the
23965 following new section:
23970 <ins>XX.X.X.X Array creation functions [array.creation]</ins>
23974 template<class... Args>
23975 array<<i>CT</i>, sizeof...(Args)>
23976 make_array(Args&&... args)
23981 <ins>Let <i>CT</i> be <tt>decay<common_type<Args...>::type>::type</tt>.</ins>
23984 <ins><i>Returns:</i> An <tt>array<<i>CT</i>, sizeof...(Args)></tt> initialized with <tt>{
23985 static_cast<<i>CT</i>>(std::forward<Args>(args))... }</tt>.</ins>
23991 <blockquote><pre><ins>
23992 int i = 0; int& ri = i;
23993 make_array(42u, i, 2.78, ri);
23994 </ins></pre></blockquote>
23996 returns an array of type
23998 <blockquote><pre><ins>
23999 array<double, 4>
24000 </ins></pre></blockquote>
24003 \97<i>end example</i>]</ins>
24019 <h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
24020 <p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
24021 <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-11 <b>Last modified:</b> 2010-10-29</p>
24022 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
24023 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
24024 <p><b>Discussion:</b></p>
24026 The main point is that <tt>capacity</tt> can be viewed as a mechanism to
24027 guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
24028 operations are used. For <tt>vector</tt>, this goes with reallocation. For
24029 <tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
24030 whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the
24031 map, as Howard did, there is very similar notion of capacity: as long
24032 as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
24033 guaranteed that no <tt>iterator</tt> is invalidated after any number of
24034 <tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not
24035 hold for other implementations.
24038 Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many
24039 <tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
24040 terators are invalidated. In a classical impl., <tt>capacity() = size()
24041 + </tt> the min distance to either "physical" end of the deque (i.e.,
24042 counting the empty space in the last block plus all the blocks until
24043 the end of the map of block pointers). In Howard's circular buffer
24044 impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
24045 this definition, even though the guarantee could be made stronger.
24048 A simple picture of a deque:
24050 <blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
24051 </pre></blockquote>
24053 (A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
24054 and - are uninitialized, + are initialized)
24055 In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
24056 (dist(A,B),dist(F,Z))</tt>.
24059 <tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
24060 empty blocks to it, in order to guarantee that the next <tt>n-size()
24061 push_back/push_front</tt> operations will not invalidate iterators, and
24062 also will not allocate (i.e. cannot throw). The second guarantee is
24063 not essential and can be left as a QoI. I know well enough existing
24064 implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
24065 dinkumware) to know that either can be implemented with no change to
24066 the existing class layout and code, and only a few modifications if
24067 blocks are pre-allocated (instead of always allocating a new block,
24068 check if the next entry in the map of block pointers is not zero).
24071 Due to the difference with <tt>vector</tt>, wording is crucial. Here's a
24072 proposed wording to make things concrete; I tried to be reasonably
24073 careful but please double-check me:
24083 Hans: should the Returns clause for capacity read "1 Returns: A lower
24084 bound..." rather than "1 Returns: An upper bound..."
24087 Howard: maybe what's needed is capacity_front and capacity_back. In
24088 fact, I think I implemented a deque that had these members as
24089 implementation details.
24095 <p><b>Proposed resolution:</b></p>
24098 Add new signatures to synopsis in 23.3.2 [deque]:
24101 <blockquote><pre>size_type capacity() const;
24102 bool reserve(size_type n);
24103 </pre></blockquote>
24106 Add new signatures to 23.3.2.2 [deque.capacity]:
24110 <pre>size_type capacity() const;
24114 1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such
24115 that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
24116 push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
24117 starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
24118 invalidate any of its iterators except to the erased elements.
24121 2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
24122 decrease after a sequence of insertions at both ends, even if none of
24123 the operations caused the <tt>deque</tt> to invalidate any of its iterators
24124 except to the erased elements.
24130 <pre>bool reserve(size_type n);
24134 2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
24135 <tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
24136 can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
24137 <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
24138 operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
24139 otherwise. If an exception is thrown, there are no effects.
24142 3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
24143 operation, and false otherwise.
24146 4 <i>Complexity:</i> It does not change the size of the sequence and takes
24147 at most linear time in <tt>n</tt>.
24150 5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>.
24153 6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
24154 sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
24155 after a call to <tt>reserve()</tt> except to the erased elements, until the
24156 time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
24157 <tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
24158 <tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
24159 <tt>reserve()</tt>.
24162 7 An implementation is free to pre-allocate buffers so as to
24163 offer the additional guarantee that no exception will be thrown
24164 during such a sequence other than by the element constructors.
24170 And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
24174 1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
24175 deque. An insertion at either end of the deque invalidates all the iterators to the deque,
24176 <ins>unless provisions have been made with reserve,</ins>
24177 but has no effect on the validity of references to elements of the deque.
24181 <p><b>Rationale:</b></p>
24182 Complication outweighs the benefit.
24189 <h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
24190 <p><b>Section:</b> 25.4.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24191 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-07-02 <b>Last modified:</b> 2010-10-29</p>
24192 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
24193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24194 <p><b>Discussion:</b></p>
24196 In 25.4.5.1 [includes] the complexity is "at most -1 comparisons" if passed
24197 two empty ranges. I don't know how to perform a negative number of
24202 This same issue also applies to:
24206 <li><tt>set_union</tt></li>
24207 <li><tt>set_intersection</tt></li>
24208 <li><tt>set_difference</tt></li>
24209 <li><tt>set_symmetric_difference</tt></li>
24210 <li><tt>merge</tt></li>
24214 2009-03-30 Beman adds:
24219 Suggest NAD. The complexity of empty ranges is -1 in other places in the
24220 standard. See 25.4.4 [alg.merge] <tt>merge</tt> and
24221 <tt>inplace_merge</tt>, and <tt>forward_list</tt> merge, for example.
24222 The time and effort to find and fix all places in the standard where
24223 empty range[s] result in negative complexity isn't worth the very
24228 2009-05-09 Alisdair adds:
24234 I'm not happy with NAD if we can find a simple solution.
24237 How about adding a rider somewhere in clause 17 suggesting that complexities
24238 that specify a negative number of operations are treated as specifying zero
24239 operations? That should generically solve the issue without looking for
24249 Pete to provide "straightforward" wording.
24250 Move to NAD Editorial.
24254 <p><b>Proposed resolution:</b></p>
24264 <h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
24265 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
24266 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2008-07-08 <b>Last modified:</b> 2010-10-29</p>
24267 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
24268 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
24269 <p><b>Discussion:</b></p>
24271 Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
24272 The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
24273 Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
24276 If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
24277 the <tt>stream</tt> should be in a failed or bad state.
24280 Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
24281 fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
24282 what is the state of the <tt>stream</tt>?
24291 Tom's impression is that the issue is about the <tt>failbit</tt>, etc.
24294 Bill responds that the stream is now closed,
24295 and any status bits remain unchanged.
24298 See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members].
24301 We prefer not to add wording to say that nothing changes.
24307 <p><b>Proposed resolution:</b></p>
24316 <h3><a name="864"></a>864. Defect in atomic wording</h3>
24317 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24318 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-07-10 <b>Last modified:</b> 2010-10-29</p>
24319 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
24320 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
24321 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24322 <p><b>Discussion:</b></p>
24324 There's an error in 29.6 [atomics.types.operations]/p9:
24328 <pre>C atomic_load(const volatile A * object);
24329 C atomic_load_explicit(const volatile A * object, memory_order);
24330 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
24334 <i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
24335 <tt>memory_order_acq_rel</tt>.
24341 I believe that this should state
24344 shall not be <tt>memory_order_release</tt>.
24348 There's also an error in 29.6 [atomics.types.operations]/p17:
24352 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
24353 is <tt>order</tt>, and
24354 the value of failure is <tt>order</tt> except that a value of
24355 <tt>memory_order_acq_rel</tt> shall be replaced by the value
24356 <tt>memory_order_require</tt> ...
24359 I believe this should state
24362 shall be replaced by the value <tt>memory_order_acquire</tt> ...
24366 <p><b>Proposed resolution:</b></p>
24368 Change 29.6 [atomics.types.operations]/p9:
24372 <pre>C atomic_load(const volatile A * object);
24373 C atomic_load_explicit(const volatile A * object, memory_order);
24374 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
24378 <i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
24379 <ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
24385 Change 29.6 [atomics.types.operations]/p17:
24389 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
24390 is <tt>order</tt>, and
24391 the value of failure is <tt>order</tt> except that a value of
24392 <tt>memory_order_acq_rel</tt> shall be replaced by the value
24393 <del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
24398 <p><b>Rationale:</b></p>
24399 Already fixed by the time the LWG processed it.
24406 <h3><a name="867"></a>867. Valarray and value-initialization</h3>
24407 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24408 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-20 <b>Last modified:</b> 2010-10-29</p>
24409 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
24410 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24411 <p><b>Discussion:</b></p>
24413 From 26.6.2.1 [valarray.cons], paragraph 2:
24416 <blockquote><pre>explicit valarray(size_t);
24419 The array created by this constructor has a length equal to the value of the argument. The elements
24420 of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
24425 The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
24426 and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
24427 the elements, so I suggest replacing:
24431 The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
24437 The elements of the array are value-initialized.
24441 There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
24442 That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
24443 and so it doesn't need changes).
24451 We agree with the proposed resolution.
24452 Move to NAD Editorial.
24456 <p><b>Proposed resolution:</b></p>
24458 Change 26.6.2.1 [valarray.cons], paragraph 2:
24462 <pre>explicit valarray(size_t);
24465 The array created by this constructor has a length equal to the value of the argument. The elements
24466 of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
24467 <ins>value-initialized (8.5 [dcl.init])</ins>.
24472 Change 26.6.2.7 [valarray.members], paragraph 9:
24476 [<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
24477 default constructor</del>
24478 <ins>value-initialized (8.5 [dcl.init])</ins>;
24479 the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
24488 <h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
24489 <p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24490 <b>Submitter:</b> Travis Vitek <b>Opened:</b> 2008-06-30 <b>Last modified:</b> 2010-10-29</p>
24491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24492 <p><b>Discussion:</b></p>
24494 Neither the term "signed integral type" nor the term "unsigned
24495 integral type" is defined in the core language section of the
24496 standard, therefore the library section should avoid its use. The
24497 terms <i>signed integer type</i> and <i>unsigned integer type</i> are
24498 indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
24499 replaced accordingly.
24503 Note that the key issue here is that "signed" + "integral type" !=
24504 "signed integral type".
24506 The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
24507 <code>char32_t</code> and <code>wchar_t</code> are all listed as
24508 integral types, but are neither of <i>signed integer type</i> or
24509 <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
24510 integral type is <i>integer type</i>.
24512 Given this, one may choose to assume that an <i>integral type</i> that
24513 can represent values less than zero is a <i>signed integral type</i>.
24514 Unfortunately this can cause ambiguities.
24516 As an example, if <code>T</code> is <code>unsigned char</code>, the
24517 expression <code>make_signed<T>::type</code>, is supposed to
24518 name a signed integral type. There are potentially two types that
24519 satisfy this requirement, namely <code>signed char</code> and
24520 <code>char</code> (assuming <code>CHAR_MIN < 0</code>).
24529 Plum, Sebor to review.
24533 Post Summit Daniel adds:
24538 The proposed resolution needs to be "conceptualized". Currently we have
24539 in [concept.support] only concept <tt>IntegralType</tt>
24540 for all "integral types", thus indeed the current <tt>Container</tt>
24541 concept and Iterator concepts are sufficiently satisfied with "integral
24542 types". If the changes are applied, we might ask core for concept
24543 <tt>BilateralIntegerType</tt> and add proper restrictions to the library
24549 <p><b>Proposed resolution:</b></p>
24551 I propose to use the terms "signed integer type" and "unsigned integer
24552 type" in place of "signed integral type" and "unsigned integral type"
24553 to eliminate such ambiguities.
24557 The proposed change makes it absolutely clear that the difference
24558 between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
24559 but could be any of the signed integer types.
24560 5.7 [expr.add] paragraph 6...
24566 When two pointers to elements of the same array object are
24567 subtracted, the result is the difference of the subscripts of
24568 the two array elements. The type of the result is an
24569 implementation-defined <del>signed integral
24570 type</del><ins>signed integer type</ins>; this type shall be the
24571 same type that is defined as <code>std::ptrdiff_t</code> in the
24572 <code><cstdint></code> header (18.1)...
24579 The proposed change makes it clear that <tt>X::size_type</tt> and
24580 <tt>X::difference_type</tt> cannot be <tt>char</tt> or
24581 <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
24582 types as appropriate.
24583 20.2.5 [allocator.requirements] table 40...
24586 Table 40: Allocator requirements
24590 <th>expression</th>
24591 <th>return type</th>
24592 <th>assertion/note/pre/post-condition</th>
24597 <td><tt>X::size_type</tt></td>
24599 <del>unsigned integral type</del>
24600 <ins>unsigned integer type</ins>
24602 <td>a type that can represent the size of the largest object in
24603 the allocation model.</td>
24606 <td><tt>X::difference_type</tt></td>
24608 <del>signed integral type</del>
24609 <ins>signed integer type</ins>
24611 <td>a type that can represent the difference between any two
24612 pointers in the allocation model.</td>
24619 The proposed change makes it clear that <tt>make_signed<T>::type</tt>
24620 must be one of the signed integer types as defined in 3.9.1. Ditto for
24621 <tt>make_unsigned<T>type</tt> and unsigned integer types.
24622 20.7.7.3 [meta.trans.sign] table 48...
24625 Table 48: Sign modifications
24636 <tt>template <class T> struct make_signed;</tt>
24639 If <code>T</code> names a (possibly cv-qualified) <del>signed
24640 integral type</del><ins>signed integer type</ins> (3.9.1) then
24641 the member typedef <code>type</code> shall name the type
24642 <code>T</code>; otherwise, if <code>T</code> names a (possibly
24643 cv-qualified) <del>unsigned integral type</del><ins>unsigned
24644 integer type</ins> then <code>type</code> shall name the
24645 corresponding <del>signed integral type</del><ins>signed
24646 integer type</ins>, with the same cv-qualifiers as
24647 <code>T</code>; otherwise, <code>type</code> shall name the
24648 <del>signed integral type</del><ins>signed integer type</ins>
24649 with the smallest rank (4.13) for which <code>sizeof(T) ==
24650 sizeof(type)</code>, with the same cv-qualifiers as
24653 <i>Requires:</i> <code>T</code> shall be a (possibly
24654 cv-qualified) integral type or enumeration but not a
24655 <code>bool</code> type.
24660 <tt>template <class T> struct make_unsigned;</tt>
24663 If <code>T</code> names a (possibly cv-qualified)
24664 <del>unsigned integral type</del><ins>unsigned integer
24665 type</ins> (3.9.1) then the member typedef <code>type</code>
24666 shall name the type <code>T</code>; otherwise, if
24667 <code>T</code> names a (possibly cv-qualified) <del>signed
24668 integral type</del><ins>signed integer type</ins> then
24669 <code>type</code> shall name the corresponding <del>unsigned
24670 integral type</del><ins>unsigned integer type</ins>, with the
24671 same cv-qualifiers as <code>T</code>; otherwise,
24672 <code>type</code> shall name the <del>unsigned integral
24673 type</del><ins>unsigned integer type</ins> with the smallest
24674 rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
24675 with the same cv-qualifiers as <code>T</code>.
24677 <i>Requires:</i> <code>T</code> shall be a (possibly
24678 cv-qualified) integral type or enumeration but not a
24679 <code>bool</code> type.
24688 Note: I believe that the basefield values should probably be
24689 prefixed with <tt>ios_base::</tt> as they are in 22.4.2.2.2 [facet.num.put.virtuals]
24691 The listed virtuals are all overloaded on signed and unsigned integer
24692 types, the new wording just maintains consistency.
24694 22.4.2.1.2 [facet.num.get.virtuals] table 78...
24697 Table 78: Integer Conversions
24702 <th><tt>stdio</tt> equivalent</th>
24707 <td><tt>basefield == oct</tt></td>
24708 <td><tt>%o</tt></td>
24711 <td><tt>basefield == hex</tt></td>
24712 <td><tt>%X</tt></td>
24715 <td><tt>basefield == 0</tt></td>
24716 <td><tt>%i</tt></td>
24719 <td><del>signed integral type</del><ins>signed integer
24721 <td><tt>%d</tt></td>
24724 <td><del>unsigned integral type</del><ins>unsigned integer
24726 <td><tt>%u</tt></td>
24735 Rationale is same as above.
24736 22.4.2.2.2 [facet.num.put.virtuals] table 80...
24739 Table 80: Integer Conversions
24744 <th><tt>stdio</tt> equivalent</th>
24749 <td><tt>basefield == ios_base::oct</tt></td>
24750 <td><tt>%o</tt></td>
24753 <td><tt>(basefield == ios_base::hex) &&
24754 !uppercase</tt></td>
24755 <td><tt>%x</tt></td>
24758 <td><tt>(basefield == ios_base::hex)</tt></td>
24759 <td><tt>%X</tt></td>
24762 <td><tt>basefield == 0</tt></td>
24763 <td><tt>%i</tt></td>
24766 <td>for a <del>signed integral type</del><ins>signed integer
24768 <td><tt>%d</tt></td>
24771 <td>for a <del>unsigned integral type</del><ins>unsigned integer
24773 <td><tt>%u</tt></td>
24781 23.2 [container.requirements] table 80...
24784 Table 89: Container requirements
24788 <th>expression</th>
24789 <th>return type</th>
24790 <th>operational semantics</th>
24791 <th>assertion/note/pre/post-condition</th>
24792 <th>complexity</th>
24797 <td><tt>X::difference_type</tt></td>
24798 <td><del>signed integral type</del><ins>signed integer type</ins></td>
24800 <td>is identical to the difference type of <tt>X::iterator</tt>
24801 and <tt>X::const_iterator</tt></td>
24802 <td>compile time</td>
24805 <td><tt>X::size_type</tt></td>
24806 <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
24808 <td><tt>size_type</tt> can represent any non-negative value of
24809 <tt>difference_type</tt></td>
24810 <td>compile time</td>
24817 X [iterator.concepts] paragraph 1...
24820 Iterators are a generalization of pointers that allow a C++ program to
24821 work with different data structures (containers) in a uniform manner.
24822 To be able to construct template algorithms that work correctly and
24823 efficiently on different types of data structures, the library
24824 formalizes not just the interfaces but also the semantics and
24825 complexity assumptions of iterators. All input iterators
24826 <code>i</code> support the expression <code>*i</code>, resulting in a
24827 value of some class, enumeration, or built-in type <code>T</code>,
24828 called the <i>value type</i> of the iterator. All output iterators
24829 support the expression <code>*i = o</code> where <code>o</code> is a
24830 value of some type that is in the set of types that are
24831 <i>writable</i> to the particular iterator type of <code>i</code>. All
24832 iterators <code>i</code> for which the expression <code>(*i).m</code>
24833 is well-defined, support the expression <code>i->m</code> with the
24834 same semantics as <code>(*i).m</code>. For every iterator type
24835 <code>X</code> for which equality is defined, there is a corresponding
24836 <del>signed integral type</del> <ins>signed integer type</ins> called
24837 the <i>difference type</i> of the iterator.
24841 I'm a little unsure of this change. Previously this paragraph would
24842 allow instantiations of <tt>linear_congruential_engine</tt> on
24843 <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
24844 new wording prohibits this.
24845 26.5.3.1 [rand.eng.lcong] paragraph 2...
24848 The template parameter <code>UIntType</code> shall denote an
24849 <del>unsigned integral type</del><ins>unsigned integer type</ins>
24850 large enough to store values as large as <code>m - 1</code>. If the
24851 template parameter <code>m</code> is 0, the modulus <code>m</code>
24852 used throughout this section 26.4.3.1 is
24853 <code>numeric_limits<result_type>::max()</code> plus 1. [Note:
24854 The result need not be representable as a value of type
24855 <code>result_type</code>. --end note] Otherwise, the following
24856 relations shall hold: <code>a < m</code> and <code>c <
24861 Same rationale as the previous change.
24862 X [rand.adapt.xor] paragraph 6...
24865 Both <code>Engine1::result_type</code> and
24866 <code>Engine2::result_type</code> shall denote (possibly different)
24867 <del>unsigned integral types</del><ins>unsigned integer types</ins>.
24868 The member <i>result_type</i> shall denote either the type
24869 <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
24870 whichever provides the most storage according to clause 3.9.1.
24874 26.5.7.1 [rand.util.seedseq] paragraph 7...
24877 <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
24878 requirements of a random access iterator (24.1.5) such that
24879 <code>iterator_traits<RandomAccessIterator>::value_type</code>
24880 shall denote an <del>unsigned integral type</del><ins>unsigned integer
24881 type</ins> capable of accomodating 32-bit quantities.
24885 By making this change, integral types that happen to have a signed
24886 representation, but are not signed integer types, would no longer be
24887 required to use a two's complement representation. This may go against
24888 the original intent, and should be reviewed.
24889 29.6 [atomics.types.operations] paragraph 24...
24892 <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
24893 types</ins>, arithmetic is defined using two's complement
24894 representation. There are no undefined results. For address types, the
24895 result may be an undefined address, but the operations otherwise have
24896 no undefined behavior.
24905 <h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
24906 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24907 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2010-10-29</p>
24908 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
24909 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24910 <p><b>Discussion:</b></p>
24912 During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a> a
24913 subrequest that adds initializer list support to
24914 <tt>discrete_distribution</tt>, specifically,
24915 the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>.
24920 <p><b>Proposed resolution:</b></p>
24924 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
24925 just <em>before</em> the member declaration
24928 <blockquote><pre>explicit discrete_distribution(const param_type& parm);
24929 </pre></blockquote>
24935 <blockquote><pre>discrete_distribution(initializer_list<double> wl);
24936 </pre></blockquote>
24941 Between p.4 and p.5 of the same section insert a new
24942 paragraph as part of the new member description:
24945 <blockquote><pre>discrete_distribution(initializer_list<double> wl);
24949 <i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
24956 <p><b>Rationale:</b></p>
24958 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
24965 <h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
24966 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
24967 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2010-10-29</p>
24968 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
24969 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
24970 <p><b>Discussion:</b></p>
24972 During the Sophia Antipolis meeting it was decided to separate from
24973 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a> a subrequest that adds initializer list support to
24974 <tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
24975 to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate
24976 weight values. For consistency with the remainder of this class and
24977 the remainder of the <tt>initializer_list</tt>-aware library the author decided to
24978 change the list argument type to the template parameter <tt>RealType</tt>
24979 instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor
24980 function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>.
24984 <p><b>Proposed resolution:</b></p>
24985 <p><b>Non-concept version of the proposed resolution</b></p>
24990 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
24991 just <em>before</em> the member declaration
24994 <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
24995 </pre></blockquote>
25001 <blockquote><pre>template<typename Func>
25002 piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
25003 </pre></blockquote>
25008 Between p.4 and p.5 of the same section insert a series of
25009 new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
25010 as part of the new member description:
25013 <blockquote><pre>template<typename Func>
25014 piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
25020 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
25024 [p5_2] <i>Requires:</i>
25029 <tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
25030 return values of a type convertible to <tt>double</tt>;
25033 The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
25034 For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
25035 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
25038 If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
25039 following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
25044 [p5_3] <i>Effects:</i>
25049 <p>If <tt>nf == 0</tt>,</p>
25052 lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
25053 value <tt>w<sub>0</sub> = 1</tt>, and
25056 lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
25065 sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
25066 length <tt>n+1</tt>, and
25069 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
25071 <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
25072 w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
25073 </pre></blockquote>
25080 Constructs a <tt>piecewise_constant_distribution</tt> object with
25081 the above computed sequence <tt>b</tt> as the interval boundaries
25082 and with the probability densities:
25084 <blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
25085 </pre></blockquote>
25095 <p><b>Concept version of the proposed resolution</b></p>
25100 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
25101 just <em>before</em> the member declaration
25104 <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
25105 </pre></blockquote>
25111 <blockquote><pre>template<Callable<auto, RealType> Func>
25112 requires Convertible<Func::result_type, double>
25113 piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
25114 </pre></blockquote>
25119 Between p.4 and p.5 of the same section insert a series of
25120 new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
25121 as part of the new member description:
25124 <blockquote><pre>template<Callable<auto, RealType> Func>
25125 requires Convertible<Func::result_type, double>
25126 piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
25132 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
25136 [p5_2] <i>Requires:</i>
25141 The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
25142 For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
25143 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
25146 If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
25147 following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
25152 [p5_3] <i>Effects:</i>
25157 <p>If <tt>nf == 0</tt>,</p>
25160 lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
25161 value <tt>w<sub>0</sub> = 1</tt>, and
25164 lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
25173 sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
25174 length <tt>n+1</tt>, and
25177 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
25179 <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
25180 w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
25181 </pre></blockquote>
25188 Constructs a <tt>piecewise_constant_distribution</tt> object with
25189 the above computed sequence <tt>b</tt> as the interval boundaries
25190 and with the probability densities:
25192 <blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
25193 </pre></blockquote>
25205 <p><b>Rationale:</b></p>
25207 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
25214 <h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
25215 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
25216 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2010-10-29</p>
25217 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
25218 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
25219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
25220 <p><b>Discussion:</b></p>
25224 the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
25225 draft</a> have introduced a gratuitous inconsistency with the C++ 2003
25226 version of the specification with respect to exception guarantees
25227 provided by standard functions. While the C++ 2003 standard
25228 consistenly uses the empty exception specification, <tt>throw()</tt>,
25229 to declare functions that are guaranteed not to throw exceptions, the
25230 current working draft contains a number of "<i>Throws:</i> Nothing."
25231 clause to specify essentially the same requirement. The difference
25232 between the two approaches is that the former specifies the behavior
25233 of programs that violate the requirement (<tt>std::unexpected()</tt>
25234 is called) while the latter leaves the behavior undefined.
25239 A survey of the working draft reveals that there are a total of 209
25240 occurrences of <tt>throw()</tt> in the library portion of the spec,
25241 the majority in clause 18, a couple (literally) in 19, a handful in
25242 20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
25247 There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
25248 throughout the spec.
25253 While sometimes there are good reasons to use the "<i>Throws:</i>
25254 Nothing." approach rather than making use of <tt>throw()</tt>, these
25255 reasons do not apply in most of the cases where this new clause has
25256 been introduced and the empty exception specification would be a
25262 First, functions declared with the empty exception specification
25263 permit compilers to generate better code for calls to such
25264 functions. In some cases, the compiler might even be able to eliminate
25265 whole chunks of user-written code when instantiating a generic
25266 template on a type whose operations invoked from the template
25267 specialization are known not to throw. The prototypical example are
25268 the <tt>std::uninitialized_copy()</tt>
25269 and <tt>std::uninitialized_fill()</tt> algorithms where the
25270 entire <tt>catch(...)</tt> block can be optimized away.
25275 For example, given the following definition of
25276 the <tt>std::uninitialized_copy</tt> function template and a
25277 user-defined type <tt>SomeType</tt>:
25281 <pre>template <class InputIterator, class ForwardIterator>
25283 uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
25285 typedef iterator_traits<ForwardIterator>::value_type ValueType;
25287 ForwardIterator start = res;
25290 for (; first != last; ++first, ++res)
25291 ::new (&*res) ValueType (*first);
25294 for (; start != res; --start)
25295 (&*start)->~ValueType ();
25302 SomeType (const SomeType&) <ins>throw ()</ins>;
25307 compilers are able to emit the following efficient specialization
25308 of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
25309 (note that the <tt>catch</tt> block has been optimized away):
25313 <pre>template <> SomeType*
25314 uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
25316 for (; first != last; ++first, ++res)
25317 ::new (res) SomeType (*first);
25324 Another general example is default constructors which, when decorated
25325 with <tt>throw()</tt>, allow the compiler to eliminate the
25326 implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
25327 emit around each the invocation of the constructor
25328 in <i>new-expressions</i>.
25333 For example, given the following definitions of
25334 class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
25339 <pre>struct MayThrow {
25344 WontThrow () <ins>throw ()</ins>;
25347 MayThrow *a = new MayThrow [N];
25348 WontThrow *b = new WontThrow [N];</pre>
25353 the compiler generates the following code for the first statement:
25359 MayThrow *first = operator new[] (N * sizeof (*a));
25360 MayThrow *last = first + N;
25361 MayThrow *next = first;
25363 for ( ; next != last; ++next)
25364 new (next) MayThrow;
25367 for ( ; first != first; --next)
25368 next->~MayThrow ();
25369 operator delete[] (first);
25377 but it is can generate much more compact code for the second statement:
25381 <pre>WontThrow *b = operator new[] (N * sizeof (*b));
25382 WontThrow *last = b + N;
25383 for (WontThrow *next = b; next != last; ++next)
25384 new (next) WontThrow;
25389 Second, in order for users to get the maximum benefit out of the new
25390 <tt>std::has_nothrow_xxx</tt> traits when using standard library types
25391 it will be important for implementations to decorate all non throwing
25392 copy constructors and assignment operators with <tt>throw()</tt>. Note
25393 that while an optimizer may be able to tell whether a function without
25394 an explicit exception specification can throw or not based on its
25395 definition, it can only do so when it can see the source code of the
25396 definition. When it can't it must assume that the function may
25397 throw. To prevent violating the One Definition Rule,
25398 the <tt>std::has_nothrow_xxx</tt> trait must return the most
25399 pessimistic guess across all translation units in the program, meaning
25400 that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
25401 <tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
25402 (where <tt>xxx</tt> is default or copy ctor, or assignment operator)
25403 is defined out-of-line.
25408 <b>Counterarguments:</b>
25413 During the discussion of this issue
25414 on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
25415 (starting with post <tt>c++std-lib-21950</tt>) the following arguments
25416 in favor of the "<i>Throws:</i> Nothing." style have been made.
25423 Decorating functions that cannot throw with the empty exception
25424 specification can cause the compiler to generate suboptimal code for
25425 the implementation of the function when it calls other functions that
25426 aren't known to the compiler not to throw (i.e., that aren't decorated
25427 with <tt>throw()</tt> even if they don't actually throw). This is a
25428 common situation when the called function is a C or POSIX function.
25433 Alternate, proprietary mechanisms exist (such as
25434 GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
25436 C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04(VS.80).aspx"><tt>__declspec(nothrow)</tt></a>)
25437 that let implementers mark up non-throwing functions, often without
25438 the penalty mentioned in (1) above. The C++ standard shouldn't
25439 preclude the use of these potentially more efficient mechanisms.
25444 There are functions, especially function templates, that invoke
25445 user-defined functions that may or may not be
25446 declared <tt>throw()</tt>. Declaring such functions with the empty
25447 exception specification will cause compilers to generate suboptimal
25448 code when the user-defined function isn't also declared not to throw.
25455 The answer to point (1) above is that implementers can (and some have)
25456 declare functions with <tt>throw()</tt> to indicate to the compiler
25457 that calls to the function can safely be assumed not to throw in order
25458 to allow it to generate efficient code at the call site without also
25459 having to define the functions the same way and causing the compiler
25460 to generate suboptimal code for the function definition. That is, the
25461 function is declared with <tt>throw()</tt> in a header but it's
25462 defined without it in the source file. The <tt>throw()</tt>
25463 declaration is suppressed when compiling the definition to avoid
25464 compiler errors. This technique, while strictly speaking no permitted
25465 by the language, is safe and has been employed in practice. For
25466 example, the GNU C library takes this approach. Microsoft Visual C++
25467 takes a similar approach by simply assuming that no function with C
25468 language linkage can throw an exception unless it's explicitly
25469 declared to do so using the language extension <tt>throw(...)</tt>.
25474 Our answer to point (2) above is that there is no existing practice
25475 where C++ Standard Library implementers have opted to make use of the
25476 proprietary mechanisms to declare functions that don't throw. The
25477 language provides a mechanism specifically designed for this
25478 purpose. Avoiding its use in the specification itself in favor of
25479 proprietary mechanisms defeats the purpose of the feature. In
25480 addition, making use of the empty exception specification
25481 inconsistently, in some areas of the standard, while conspicuously
25482 avoiding it and making use of the "<i>Throws:</i> Nothing." form in
25483 others is confusing to users.
25488 The answer to point (3) is simply to exercise caution when declaring
25489 functions and especially function templates with the empty exception
25490 specification. Functions that required not to throw but that may call
25491 back into user code are poor candidates for the empty exception
25492 specification and should instead be specified using "<i>Throws:</i>
25504 We need someone to do an extensive review.
25512 <p><b>Proposed resolution:</b></p>
25515 We propose two possible solutions. Our recommendation is to adopt
25526 Except for functions or function templates that make calls back to
25527 user-defined functions that may not be declared <tt>throw()</tt>
25528 replace all occurrences of the "<i>Throws:</i> Nothing." clause with
25529 the empty exception specification. Functions that are required not to
25530 throw but that make calls back to user code should be specified to
25531 "<i>Throw:</i> Nothing."
25541 For consistency, replace all occurrences of the empty exception
25542 specification with a "<i>Throws:</i> Nothing." clause.
25550 <h3><a name="879"></a>879. Atomic load const qualification</h3>
25551 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
25552 <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2010-10-29</p>
25553 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
25554 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
25555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
25556 <p><b>Discussion:</b></p>
25558 The <tt>atomic_address</tt> type and <tt>atomic<T*></tt> specialization provide atomic
25559 updates to pointers. However, the current specification requires
25560 that the types pointer be to non-const objects. This restriction
25561 is unnecessary and unintended.
25569 Move to review. Lawrence will first check with Peter whether the
25570 current examples are sufficient, or whether they need to be expanded to
25581 Lawrence will handle all issues relating to atomics in a single paper.
25584 LWG will defer discussion on atomics until that paper appears.
25592 2009-08-17 Handled by
25593 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25598 2009-10 Santa Cruz:
25603 NAD Editorial. Solved by
25604 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25609 <p><b>Proposed resolution:</b></p>
25611 Add const qualification to the pointer values of the <tt>atomic_address</tt>
25612 and <tt>atomic<T*></tt> specializations. E.g.
25615 <blockquote><pre>typedef struct atomic_address {
25616 void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
25617 void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
25618 bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
25619 memory_order, memory_order) volatile;
25620 bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
25621 memory_order = memory_order_seq_cst ) volatile;
25622 void* operator=(<ins>const</ins> void*) volatile;
25625 void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
25626 void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
25628 void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
25629 void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
25631 bool atomic_compare_exchange(volatile atomic_address*,
25632 <ins>const</ins> void**, <ins>const</ins> void*);
25633 bool atomic_compare_exchange_explicit(volatile atomic_address*,
25634 <ins>const</ins> void**, <ins>const</ins> void*,
25635 memory_order, memory_order);
25636 </pre></blockquote>
25643 <h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
25644 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
25645 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2010-10-29</p>
25646 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
25647 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
25648 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
25649 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
25650 <p><b>Discussion:</b></p>
25652 The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
25653 be inconsistently missing parameters.
25663 Lawrence: Need to write up a list for Pete with details.
25666 Detlef: Should not be New, we already talked about in Concurrency group.
25680 Lawrence will handle all issues relating to atomics in a single paper.
25683 LWG will defer discussion on atomics until that paper appears.
25691 2009-08-17 Handled by
25692 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25697 2009-10 Santa Cruz:
25702 NAD Editorial. Solved by
25703 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25708 <p><b>Proposed resolution:</b></p>
25710 Add the appropriate parameters. For example,
25713 <blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
25714 bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
25715 </pre></blockquote>
25722 <h3><a name="887"></a>887. issue with condition::wait_...</h3>
25723 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
25724 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
25725 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
25726 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
25727 <p><b>Discussion:</b></p>
25729 The Posix/C++ working group has identified an inconsistency between
25730 Posix and the C++ working draft in that Posix requires the clock to be
25731 identified at creation, whereas C++ permits identifying the clock at the
25732 call to wait. The latter cannot be implemented with the former.
25742 Howard recommends NAD with the following explanation:
25746 The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
25747 be able to handle user-defined clocks as well as clocks the system knows about.
25748 This can be done by providing overloads for the known clocks, and another
25749 overload for unknown clocks which synchs to a known clock before waiting.
25753 <blockquote><pre>template <class Duration>
25755 condition_variable::wait_until(unique_lock<mutex>& lock,
25756 const chrono::time_point<chrono::system_clock, Duration>& abs_time)
25758 using namespace chrono;
25759 nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch());
25760 __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d));
25761 return system_clock::now() < abs_time;
25764 template <class Clock, class Duration>
25766 condition_variable::wait_until(unique_lock<mutex>& lock,
25767 const chrono::time_point<Clock, Duration>& abs_time)
25769 using namespace chrono;
25770 system_clock::time_point s_entry = system_clock::now();
25771 typename Clock::time_point c_entry = Clock::now();
25772 nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() -
25773 c_entry.time_since_epoch());
25774 __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn);
25775 return Clock::now() < abs_time;
25777 </pre></blockquote>
25780 In the above example, <tt>system_clock</tt> is the only clock which the underlying
25781 condition variable knows how to deal with. One overload just passes that clock
25782 through. The second overload (approximately) converts the unknown clock into
25783 a <tt>system_clock time_point</tt> prior to passing it down to the native
25784 condition variable.
25788 On Posix systems vendors are free to add implementation defined constructors which
25789 take a clock. That clock can be stored in the condition_variable, and converted
25790 to (or not as necessary) as shown above.
25794 If an implementation defined constructor takes a clock (for example), then part
25795 of the semantics for that implementation defined ctor might include that a
25796 <tt>wait_until</tt> using a clock other than the one constructed with results
25797 in an error (exceptional condition) instead of a conversion to the stored clock.
25798 Such a design is up to the vendor as once an implementation defined ctor is used,
25799 the vendor is free to specifiy the behavior of waits and/or notifies however
25800 he pleases (when the cv is constructed in an implementation defined manner).
25811 "POSIX people will review the proposed NAD resolution at their upcoming NY
25816 See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
25830 2009-07-18 Detlef reopens the issue:
25836 On Friday afternoon in Frankfurt is was decided that 887 is NAD.
25837 This decision was mainly based on a sample implementation presented
25838 by Howard that implemented one clock on top of another.
25839 Unfortunately this implementation doesn't work for the probably most
25840 important case where a system has a monotonic clock and a real-time
25841 clock (or "wall time" clock):
25844 If the underlying "system_clock" is a monotonic clock, and
25845 the program waits on the real-time clock, and the real-time clock
25846 is set forward, the wait will unblock too late.
25850 If the underlying "system_clock" is a real-time clock, and the
25851 program waits on the monotonic clock, and the real-time clock
25852 is set back, the wait again will unblock too late.
25856 Sorry that I didn't remember this on Friday, but it was Friday
25857 afternoon after a busy week...
25861 So as the decision was made on a wrong asumption, I propose to re-open
25867 2009-07-26 Howard adds:
25873 Detlef correctly argues that <tt>condition_variable::wait_until</tt> could
25874 return "too late" in the context of clocks being adjusted during the wait. I agree
25875 with his logic. But I disagree that this makes this interface unimplementable
25880 The POSIX spec also does not guarantee that <tt>pthread_cond_timedwait</tt> does
25881 not return "too late" when clocks are readjusted during the wait. Indeed, the
25882 POSIX specification lacks any requirements at all concerning how soon
25883 <tt>pthread_cond_timedwait</tt> returns after a time out. This is evidently a
25884 QOI issue by the POSIX standard. Here is a quote of the most relevant normative
25885 text concerning <tt>pthread_cond_timedwait</tt> found
25886 <a href="http://www.unix.org/single_unix_specification/">here</a>.
25890 The <tt>pthread_cond_timedwait()</tt> function shall be equivalent to
25891 <tt>pthread_cond_wait()</tt>, except that an error is returned if the absolute
25892 time specified by <tt>abstime</tt> passes (that is, system time equals or exceeds
25893 <tt>abstime</tt>) before the condition <tt>cond</tt> is signaled or broadcasted, or if the
25894 absolute time specified by <tt>abstime</tt> has already been passed at the time
25899 I.e. the POSIX specification speaks of the error code returned in case of a time
25900 out, but not on the timeliness of that return.
25904 Might this simply be an oversight, or minor defect in the POSIX specification?
25908 I do not believe so. This same section goes on to say in <em>non-normative</em>
25913 For cases when the system clock is advanced discontinuously by an
25914 operator, it is expected that implementations process any timed wait
25915 expiring at an intervening time as if that time had actually occurred.
25919 Here is non-normative wording encouraging the implementation to ignore an advancing
25920 underlying clock and subsequently causing an early (spurious) return. There is
25921 no wording at all which addresses Detlef's example of a "late return". With
25922 <tt>pthread_cond_timedwait</tt> this would be caused by setting the system clock
25923 backwards. It seems reasonable to assume, based on the wording that is already
25924 in the POSIX spec, that again, the discontinuously changed clock would be ignored
25925 by <tt>pthread_cond_timedwait</tt>.
25929 A noteworthy difference between <tt>pthread_cond_timedwait</tt> and
25930 <tt>condition_variable::wait_until</tt> is that the POSIX spec appears to
25931 say that <tt>ETIMEDOUT</tt> should be returned if <tt>pthread_cond_timedwait</tt>
25932 returns because of timeout signal, whether or not the system clock was discontinuously
25933 advanced during the wait. In contrast <tt>condition_variable::wait_until</tt>
25937 <blockquote><pre><tt>Clock::now() < abs_time</tt>
25938 </pre></blockquote>
25941 That is, the C++ spec requires that the clock be rechecked (detecting discontinuous
25942 adjustments during the wait) at the time of return. <tt>condition_variable::wait_until</tt>
25943 may indeed return early or late. But regardless it will return a value
25944 reflecting timeout status at the time of return (even if clocks have been adjusted).
25945 Of course the clock may be adjusted after the return value is computed but before the client has
25946 a chance to read the result of the return. Thus there are no iron-clad guarantees
25951 <tt>condition_variable::wait_until</tt> (and <tt>pthread_cond_timedwait</tt>)
25952 is little more than a convenience function for making sure
25953 <tt>condition_variable::wait</tt> doesn't hang for an unreasonable amount of
25954 time (where the client gets to define "unreasonable"). I do not think it
25955 is in anyone's interest to try to make it into anything more than that.
25959 I maintain that this is a useful and flexible specification in the spirit of
25960 C++, and is implementable on POSIX. The implementation technique described above
25961 is a reasonable approach. There may also be higher quality approaches. This
25962 specification, like the POSIX specification, gives a wide latitude for QOI.
25966 I continue to recommend NAD, but would not object to a clarifying note regarding
25967 the behavior of <tt>condition_variable::wait_until</tt>. At the moment, I do
25968 not have good wording for such a note, but welcome suggestions.
25974 2009-09-30: See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2969.html">N2969</a>.
25979 2009-10 Santa Cruz:
25984 The LWG is in favor of Detlef to supply revision which adopts Option 2 from
25985 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2969.html">N2969</a>
25986 but is modified by saying that <tt>system_clock</tt> must be available for <tt>wait_until</tt>.
25990 2010-02-11 Anthony provided wording.
25995 2010-02-22 Anthony adds:
26001 I am strongly against
26002 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html">N2999</a>.
26006 Firstly, I think that the most appropriate use of a timed wait on a condition
26007 variable is with a monotonic clock, so it ought to be guaranteed to be available
26008 on systems that support such a clock. Also, making the set of supported clocks
26009 implementation defined essentially kills portability around the use of
26010 user-defined clocks.
26014 I also think that <tt>wait_for</tt> is potentially useful, and trivially
26015 implementable given a working templated <tt>wait_until</tt> and a monotonic
26020 I also disagree with many of Detlef's points in the rationale. In a system with
26021 hard latency limits there is likely to be a monotonic clock, otherwise you have
26022 no way of measuring against these latency limits since the <tt>system_clock</tt>
26023 may change arbitrarily. In such systems, you <em>want</em> to be able to use
26024 <tt>wait_for</tt>, or <tt>wait_until</tt> with a monotonic clock.
26028 I disagree that the <tt>wait_*</tt> functions cannot be implemented correctly on
26029 top of POSIX: I have done so. The only guarantee in the working draft is that
26030 when the function returns certain properties are true; there is no guarantee
26031 that the function will return <em>immediately</em> that the properties are true.
26032 My resolution to issue 887 makes this clear. How small the latency is is QoI.
26036 On systems without a monotonic clock, you cannot measure the problem since the
26037 system clock can change arbitrarily so any timing calculations you make may be
26038 wrong due to clock changes.
26042 On systems with a monotonic clock, you can choose to use it for your condition
26043 variables. If you are waiting against a <tt>system_clock::time_point</tt> then
26044 you can check the clock when waking, and either return as a timeout or spurious
26045 wake depending on whether <tt>system_clock::now()</tt> is before or after the
26046 specified <tt>time_point</tt>.
26050 Windows <em>does</em> provide condition variables from Vista onwards. I choose
26051 not to use them, but they are there. If people are concerned about
26052 implementation difficulty, the Boost implementation can be used for most
26053 purposes; the Boost license is pretty liberal in that regard.
26057 My preferred resolution to issue 887 is currently the PR in the issues list.
26068 There is no consensus for moving the related paper
26069 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html">N2999</a>
26073 There was support for moving this issue as proposed to Ready, but the support
26074 was insufficient to call a consensus.
26077 There was consensus for moving this issue to NAD as opposed to leaving it open.
26084 <p><b>Rationale:</b></p>
26086 The standard as written is sufficiently implementable and self consistent.
26090 <p><b>Proposed resolution:</b></p>
26092 Add a new paragraph after 30.2.4 [thread.req.timing]p3:
26097 3 The resolution of timing provided by an implementation depends on both
26098 operating system and hardware. The finest resolution provided by an
26099 implementation is called the <i>native resolution</i>.
26103 If a function in this clause takes a timeout argument, and the time point or
26104 elapsed time specified passes before the function returns, the latency between
26105 the timeout occurring and the function returning is unspecified [<i>Note:</i>
26106 Implementations should strive to keep such latency as small as possible, but
26107 portable code should not rely on any specific upper limits
\97 <i>end
26117 <h3><a name="889"></a>889. thread::id comparisons</h3>
26118 <p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
26119 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
26120 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
26121 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
26122 <p><b>Discussion:</b></p>
26124 <p><b>Addresses UK 324</b></p>
26127 The <tt>thread::id</tt> type supports the full set of comparison operators. This
26128 is substantially more than is required for the associative containers that
26129 justified them. Please place an issue against the threads library.
26139 Would depend on proposed extension to POSIX, or non-standard extension.
26140 What about hash? POSIX discussing op. POSIX not known to be considering
26141 support needed for hash, op.
26144 Group expresses support for putting ids in both unordered and ordered containers.
26149 post San Francisco:
26155 Howard: It turns out the current working paper
26156 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
26157 <i>already has</i> <tt>hash<thread::id></tt>
26158 (20.8 [function.objects], 20.8.15 [unord.hash]). We simply
26159 overlooked it in the meeting. It is a good thing we voted in favor of it
26174 Recommend to close as NAD. For POSIX, see if we need to add a function to
26175 convert <tt>pthread_t</tt> to integer.
26179 Post Summit, Alisdair adds:
26185 The recommendation for LWG-889/UK-324 is NAD, already specified.
26188 It is not clear to me that the specification is complete.
26191 In particular, the synopsis of <tt><functional></tt> in 20.8 [function.objects] does not mention <tt>hash< thread::id
26192 ></tt> nor <tt>hash< error_code ></tt>, although their
26193 existence is implied by 20.8.15 [unord.hash], p1.
26196 I am fairly uncomfortable putting the declaration for the
26197 <tt>thread_id</tt> specialization into <tt><functional></tt> as
26198 <tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
26199 that <tt><functional></tt> would require the definition of the
26200 <tt>thread</tt> class template in order to forward declared
26201 <tt>thread::id</tt> and form this specialization.
26204 It seems better to me that the dependency goes the other way around
26205 (<tt><thread></tt> will more typically make use of
26206 <tt><functional></tt> than vice-versa) and the
26207 <tt>hash<thread::id></tt> specialization be declared in the
26208 <tt><thread></tt> header.
26211 I think <tt>hash<error_code></tt> could go into either
26212 <tt><system_error></tt> or <tt><functional></tt> and have no
26213 immediate preference either way. However, it should clearly appear in
26214 the synopsis of one of these two.
26217 Recommend moving 889 back to open, and tying in a reference to UK-324.
26226 Howard observes that <tt>thread::id</tt> need not be a nested class;
26227 it could be a <tt>typedef</tt> for a more visible type.
26231 2009-05-24 Alisdair adds:
26235 I do not believe this is correct. <tt>thread::id</tt> is explicitly documents as a
26236 nested class, rather than as an unspecified typedef analogous to an
26237 iterator. If the intent is that this is not implemented as a nested class
26238 (under the as-if freedoms) then this is a novel form of standardese.
26247 Decided we want to move hash specialization for thread_id to the thread
26248 header. Alisdair to provide wording.
26252 2009-07-28 Alisdair provided wording, moved to Review.
26257 2009-10 Santa Cruz:
26262 Add a strike for <tt>hash<thread::id></tt>. Move to Ready
26266 2009-11-13 The proposed wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a> is a superset of the
26267 wording in this issue.
26272 2010-02-09 Moved from Ready to Open:
26278 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a> is not quite a superset of this issue and it is controversial
26279 whether or not the note:
26283 hash template specialization allows <tt>thread::id</tt> objects to be used as keys in
26284 unordered containers.
26288 should be added to the WP.
26295 2010-02-09 Objections to moving this to NAD Editorial, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a> have been removed. Set to Tentatively NAD Editorial.
26301 <p><b>Rationale:</b></p>
26303 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
26307 <p><b>Proposed resolution:</b></p>
26310 Remove the following prototype from the synopsis in
26311 20.8 [function.objects]:
26314 <blockquote><pre><del>
26315 template <> struct hash<std::thread::id>;
26316 </del></pre></blockquote>
26319 Add to 30.3 [thread.threads], p1 Header <tt><thread></tt> synopsis:
26322 <blockquote><pre><ins>template <class T> struct hash;
26323 template <> struct hash<thread::id>;</ins>
26324 </pre></blockquote>
26327 Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
26330 <blockquote><pre><ins>template <>
26331 struct hash<thread::id> : public unary_function<thread::id, size_t> {
26332 size_t operator()(thread::id val) const;
26334 </pre></blockquote>
26337 Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
26341 [<i>Note:</i> Relational operators allow <tt>thread::id</tt> objects to be used
26342 as keys in associative containers.
26343 <ins><tt>hash</tt> template specialization allows <tt>thread::id</tt> objects to be used as keys
26344 in unordered containers.</ins>
26345 \97 <i>end note</i>]
26349 Add new paragraph to end of 30.3.1.1 [thread.thread.id]
26352 <blockquote><pre><ins>template <> struct hash<thread::id>;</ins>
26355 An explicit specialization of the class template hash (20.8.15 [unord.hash])
26356 shall be provided for the type <tt>thread::id</tt>.
26357 </ins></blockquote>
26365 <h3><a name="892"></a>892. Forward_list issues...</h3>
26366 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
26367 <b>Submitter:</b> Ed Smith-Rowland <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
26368 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
26369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
26370 <p><b>Discussion:</b></p>
26372 I was looking at the latest draft on <tt>forward_list</tt>. Especially the splice methods.
26375 The first one splices a whole list after a given iterator in <tt>this</tt>. The name is <tt>splice_after</tt>.
26376 I think in 23.3.3.5 [forwardlist.ops] paragraph 40
26380 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
26384 A deeper issue involves the complexity. <tt>forward_list</tt> has no <tt>size</tt> and we
26385 don't know when we've reached the end except to walk up to it. To
26386 splice we would need to hook the end of the source list to the item
26387 after <tt>position</tt> in this list. This would involve walking length of the
26388 source list until we got to the last dereference-able element in source.
26389 There's no way we could do this in O(1) unless we stored a bogus end in
26390 <tt>forward_list</tt>.
26393 OTOH, the last version of <tt>splice_after</tt> with iterator ranges we could do
26394 in O(1) because we know how to hook the end of the source range to ...
26397 Unless I'm misconceiving the whole thing. Which is possible. I'll look at it again.
26400 I'm pretty sure about the first part though.
26410 This issue is more complicated than it looks.
26413 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
26416 add a statement after paragraph 48 that complexity is O(1)
26419 remove the complexity statement from the first overload of splice_after
26422 We may have the same problems with other modifiers, like erase_after.
26423 Should it require that all iterators in the range (position, last] be
26427 We do, however, like the proposed changes and consider them Editorial.
26428 Move to NAD Editorial, Pending. Howard to open a new issue to handle the
26429 problems with the complexity requirements.
26432 Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>.
26437 <p><b>Proposed resolution:</b></p>
26439 In 23.3.3.5 [forwardlist.ops] paragraph 40
26443 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
26451 <h3><a name="895"></a>895. "Requires:" on std::string::at et al</h3>
26452 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
26453 <b>Submitter:</b> James Dennett <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2010-10-29</p>
26454 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
26455 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
26456 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a></p>
26457 <p><b>Discussion:</b></p>
26459 Per discussion, we need an issue open to cover looking at "Requires"
26460 clauses which are not constraints on user code, such as that on
26461 <tt>std::basic_string::at</tt>.
26470 Alan to address in paper.
26475 <p><b>Proposed resolution:</b></p>
26484 <h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
26485 <p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
26486 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22 <b>Last modified:</b> 2010-10-29</p>
26487 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.modifiers">issues</a> in [forwardlist.modifiers].</p>
26488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
26489 <p><b>Discussion:</b></p>
26491 This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG.
26501 This issue is more complicated than it looks.
26504 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
26507 add a statement after paragraph 48 that complexity is O(1)
26510 remove the complexity statement from the first overload of splice_after
26513 We may have the same problems with other modifiers, like erase_after.
26514 Should it require that all iterators in the range (position, last] be
26520 There are actually 3 issues here:
26526 What value should <tt>erase_after</tt> return? With <tt>list</tt>, code often
26529 <blockquote><pre>for (auto i = l.begin(); i != l.end();)
26531 // inspect *i and decide if you want to erase it
26533 if (I want to erase *i)
26538 </pre></blockquote>
26540 I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
26541 logic for operating on the next element. For <tt>forward_list</tt> this might
26542 look something like:
26544 <blockquote><pre>auto i = fl.before_begin();
26546 for (++ip1; ip1 != fl.end(); ++ip1)
26548 // inspect *(i+1) and decide if you want to erase it
26550 if (I want to erase *(i+1))
26551 i = fl.erase_after(i);
26556 </pre></blockquote>
26558 In the above example code, it is convenient if <tt>erase_after</tt> returns
26559 the element <i>prior</i> to the erased element (range) instead of the element
26560 <i>after</i> the erase element (range).
26566 <li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
26567 <li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
26570 There is not a strong technical argument for either solution over the other.
26576 With all other containers, operations always work on the range
26577 <tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
26580 With <tt>forward_list</tt>, operations sometimes work on the range
26581 <tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
26584 This is simply due to the fact that in order to operate on
26585 <tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
26586 <tt>*(first-1)</tt>. And that's not practical with
26587 <tt>forward_list</tt>. So the operating range needs to start with <tt>(first</tt>,
26588 not <tt>[first</tt> (as the current working paper says).
26591 Additionally, if one is interested in splicing the range <tt>(first, last)</tt>,
26592 then (with <tt>forward_list</tt>), one needs practical (constant time) access to
26593 <tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
26594 the proper value. As this is not possible with <tt>forward_list</tt>, one must
26595 specify the last element of interest instead of one past the last element of
26596 interest. The syntax for doing this is to pass <tt>(first, last]</tt> instead
26597 of <tt>(first, last)</tt>.
26600 With <tt>erase_after</tt> we have a choice of either erasing the range
26601 <tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>. Choosing the latter
26604 <blockquote><pre>x.erase_after(pos, x.end());
26605 </pre></blockquote>
26608 With the former, the above statement is inconvenient or expensive due to the lack
26609 of constant time access to <tt>x.end()-1</tt>. However we could introduce:
26612 <blockquote><pre>iterator erase_to_end(const_iterator position);
26613 </pre></blockquote>
26620 The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
26621 is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
26622 as the specified range. But this either requires the addition of <tt>erase_to_end</tt>
26623 or giving up such functionality.
26629 As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above,
26630 a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
26631 if the operation is to be <i>Ο</i>(1). When splicing an entire list <tt>x</tt> the
26632 algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>. Unfortunately <tt>x.end()-1</tt>
26633 is not available in constant time unless we specify that it must be. In order to
26634 make <tt>x.end()-1</tt> available in constant time, the implementation would have
26635 to dedicate a pointer to it. I believe the design of
26636 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
26637 intended a nominal overhead of <tt>foward_list</tt> of 1 pointer. Thus splicing
26638 one <i>entire</i> <tt>forward_list</tt> into another can not be <i>Ο</i>(1).
26648 We agree with the proposed resolution.
26662 We may need a new issue to correct splice_after, because it may no
26663 longer be correct to accept an rvalues as an argument. Merge may be
26664 affected, too. This might be issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>. (Howard: confirmed)
26667 Move this to Ready, but the Requires clause of the second form of
26668 splice_after should say "(first, last)," not "(first, last]" (there are
26669 three occurrences). There was considerable discussion on this. (Howard: fixed)
26672 Alan suggested removing the "foward_last<T. Alloc>&& x"
26673 parameter from the second form of splice_after, because it is redundant.
26674 PJP wanted to keep it, because it allows him to check for bad ranges
26675 (i.e. "Granny knots").
26678 We prefer to keep <tt>x</tt>.
26681 Beman. Whenever we deviate from the customary half-open range in the
26682 specification, we should add a non-normative comment to the standard
26683 explaining the deviation. This clarifies the intention and spares the
26684 committee much confusion in the future.
26687 Alan to write a non-normative comment to explain the use of fully-closed ranges.
26690 Move to Ready, with the changes described above. (Howard: awaiting note from Alan)
26695 2009-10 Santa Cruz:
26700 NAD Editorial, addressed by
26701 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2988.pdf">N2988</a>.
26706 <p><b>Proposed resolution:</b></p>
26708 Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a> is accepted, but this issue is
26709 independent of that issue.
26713 Change 23.3.3.4 [forwardlist.modifiers]:
26717 <pre>iterator erase_after(const_iterator position);
26721 <i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
26724 <i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
26727 <i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such
26728 element exists</del>
26729 <ins>An iterator equal to <tt>position</tt></ins>.
26734 <pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
26738 <i>Requires:</i> All iterators in the range
26739 <tt><del>[</del><ins>(</ins>position,last)</tt>
26740 are dereferenceable.
26743 <i>Effects:</i> Erases the elements in the range
26744 <tt><del>[</del><ins>(</ins>position,last)</tt>.
26747 <i>Returns:</i> <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
26753 Change 23.3.3.5 [forwardlist.ops]:
26757 <pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x);
26761 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
26762 dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&x != this</tt>.
26765 <i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
26766 <tt>x</tt> becomes empty. Pointers and references to
26767 the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
26768 Iterators referring to the moved elements will continue to refer to their elements,
26769 but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
26772 <i>Throws:</i> Nothing.
26775 <i>Complexity:</i> <del><i>Ο</i>(1)</del> <ins><i>Ο</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
26781 <pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x,
26782 const_iterator first, const_iterator last);
26786 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
26787 dereferenceable iterator in the range <tt>[begin(), end))</tt>.
26788 <tt>(first,last)</tt> is a valid range in
26789 <tt>x</tt>, and all iterators in the range
26790 <tt>(first,last)</tt> are dereferenceable.
26791 <tt>position</tt> is not an iterator in the range <tt>(first,last)</tt>.
26794 <i>Effects:</i> Inserts elements in the range <tt>(first,last)</tt>
26795 after <tt>position</tt> and removes the elements from <tt>x</tt>.
26796 Pointers and references to the moved elements of <tt>x</tt> now refer to
26797 those same elements but as members of <tt>*this</tt>. Iterators
26798 referring to the moved elements will continue to refer to their
26799 elements, but they now behave as iterators into <tt>*this</tt>, not into
26803 <ins><i>Complexity:</i> <i>Ο</i>(1).</ins>
26815 <h3><a name="901"></a>901. insert iterators can move from lvalues</h3>
26816 <p><b>Section:</b> 24.5.2.5 [insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
26817 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2010-10-29</p>
26818 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
26819 <p><b>Discussion:</b></p>
26820 <p><b>Addresses UK 282</b></p>
26823 The requires clause on the <tt>const T &</tt> overloads in
26824 <tt>back_insert_iterator/front_insert_iterator/insert_iterator</tt> mean that the
26825 assignment operator will implicitly move from lvalues of a move-only type.
26828 Suggested resolutions are:
26832 Add another overload with a negative constraint on copy-constructible
26833 and flag it "= delete".
26836 Drop the copy-constructible overload entirely and rely on perfect
26837 forwarding to catch move issues one level deeper.
26840 This is a fundamental problem in move-syntax that relies on the
26841 presence of two overloads, and we need to look more deeply into this
26842 area as a whole - do not solve this issue in isolation.
26847 Post Summit, Alisdair adds:
26853 Both comment and issue have been resolved by the adoption of
26854 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
26855 (rvalue references safety fix) at the last meeting.
26859 Suggest resolve as NAD Editorial with a reference to the paper.
26868 We agree that this has been resolved in the latest Working Draft.
26873 <p><b>Proposed resolution:</b></p>
26875 Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
26883 <h3><a name="902"></a>902. Regular is the wrong concept to constrain numeric_limits</h3>
26884 <p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
26885 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2010-10-29</p>
26886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
26887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
26888 <p><b>Discussion:</b></p>
26890 <p><b>Addresses FR 32 and DE 16</b></p>
26893 <tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
26894 break the model of <tt>Regular</tt> (via its axioms.) While floating point types
26895 will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
26896 appopriate for this specific API and we need a less refined constraint.
26902 The definition of <tt>numeric_limits<></tt> as requiring a regular
26903 type is both conceptually wrong and operationally illogical. As we
26904 pointed before, this mistake needs to be corrected. For example, the
26905 template can be left unconstrained. In fact this reflects a much more
26906 general problem with concept_maps/axioms and their interpretations. It
26907 appears that the current text heavily leans toward experimental academic
26914 The class template <tt>numeric_limits</tt> should not specify the Regular concept
26915 requirement for its template parameter, because it contains functions
26916 returning NaN values for floating-point types; these values violate the
26917 semantics of EqualityComparable.
26926 Move to Open. Alisdair and Gaby will work on a solution, along with the new
26927 treatment of axioms in clause 14.
26932 <p><b>Proposed resolution:</b></p>
26941 <h3><a name="903"></a>903. <tt>back_insert_iterator</tt> issue</h3>
26942 <p><b>Section:</b> 24.5.2.1 [back.insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
26943 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2008-09-19 <b>Last modified:</b> 2010-10-29</p>
26944 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
26945 <p><b>Discussion:</b></p>
26947 I just noticed this; don't know how far the problem(?) extends or
26948 whether it's new or existing: <tt>back_insert_iterator</tt>'s <tt>operator*</tt> is not
26949 <tt>const</tt>, so you can't dereference a <tt>const</tt> one.
26953 Post Summit Daniel adds:
26959 If done, this change should be applied for <tt>front_insert_iterator</tt>,
26960 <tt>insert_iterator</tt>, <tt>ostream_iterator</tt>, and <tt>ostreambuf_iterator</tt> as well.
26970 Alisdair notes that these all are output iterators.
26971 Howard points out that <tt>++*i</tt>
26972 would no longer work if we made this change.
26980 2009-05-25 Daniel adds:
26986 If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a> is accepted, <tt>OutputIterator</tt> does no longer support post increment.
26989 To support backward compatibility a second overload of <tt>operator*</tt>
26991 Note that the <tt>HasDereference</tt> concept (and the <tt>HasDereference</tt> part of concept
26992 <tt>Iterator</tt>) was specifically refactored to cope with optional const
26994 to properly reflect the dual nature of built-in <tt>operator*</tt> as of
26995 13.5.8 [over.literal]/6.
27000 <p><b>Proposed resolution:</b></p>
27007 <h3><a name="905"></a>905. Mutex specification questions</h3>
27008 <p><b>Section:</b> 30.4.1.2.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
27009 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2010-10-29</p>
27010 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
27011 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
27012 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a></p>
27013 <p><b>Discussion:</b></p>
27015 A few questions on the current WP,
27016 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>:
27019 30.4.1 [thread.mutex.requirements]/24 says an expression
27020 <tt>mut.unlock()</tt> "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The
27021 calling thread shall own the mutex" opens the door for throwing an
27022 exception anyway, such as to report unbalanced unlock operations and
27023 unlocking from a thread that does not have ownership. Right?
27026 30.4.1.2.1 [thread.mutex.class]/3 (actually numbered paragraph "27"
27027 in the WP; this is just a typo I think) says
27031 The behavior of a program is undefined if:
27034 <li>it destroys a <tt>mutex</tt> object owned by any thread,</li>
27035 <li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</li>
27036 <li>a thread terminates while owning a <tt>mutex</tt> object.</li>
27041 As already discussed, I think the second bullet should be removed, and
27042 such a <tt>lock()</tt> or <tt>try_lock()</tt> should fail with an
27043 exception or returning <tt>false</tt>, respectively.
27046 A potential addition to the list would be
27049 <li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li>
27052 but without that the status quo text endorses the technique of the
27053 program logically transferring ownership of a mutex to another thread
27054 with correctness enforced by programming discipline. Was that intended?
27064 Two resolutions: "not a defect" and "duplicate", as follows:
27068 30.4.1 [thread.mutex.requirements]/24: NAD. If the precondition
27069 fails the program has undefined behaviour and therefore an
27070 implementation may throw an exception already.
27073 30.4.1.2.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>.
27076 30.4.1.2.1 [thread.mutex.class]/3 proposed addition: NAD. This is
27077 already covered by the mutex requirements, which have ownership as a
27084 <p><b>Proposed resolution:</b></p>
27092 <h3><a name="906"></a>906. <tt>ObjectType</tt> is the wrong concept to constrain <tt>initializer_list</tt></h3>
27093 <p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
27094 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
27095 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
27096 <p><b>Discussion:</b></p>
27098 The currently proposed constraint on <tt>initializer_list</tt>'s element type
27099 <tt>E</tt> is that is has to meet <tt>ObjectType</tt>. This is an underspecification,
27100 because both core language and library part of <tt>initializer_list</tt>
27101 make clear, that it references an implicitly allocated array:
27104 8.5.4 [dcl.init.list]/4:
27107 When an initializer list is implicitly converted to a
27108 <tt>std::initializer_list<E></tt>, the object passed is constructed as if the
27109 implementation allocated an array of N elements of type <tt>E</tt>, where
27110 N is the number of elements in the initializer list.[..]
27114 18.9 [support.initlist]/2.
27118 An object of type <tt>initializer_list<E></tt> provides access to an array of
27119 objects of type <tt>const E</tt>.[..]
27123 Therefore, <tt>E</tt> needs to fulfill concept <tt>ValueType</tt> (thus excluding
27124 abstract class types). This stricter requirement should be added
27125 to prevent deep instantiation errors known from the bad old times,
27126 as shown in the following example:
27129 <blockquote><pre>// Header A: (Should concept-check even in stand-alone modus)
27131 template <DefaultConstructible T>
27132 requires MoveConstructible<T>
27133 void generate_and_do_3(T a) {
27134 std::initializer_list<T> list{T(), std::move(a), T()};
27139 void do_more_or_less();
27141 template <DefaultConstructible T>
27142 requires MoveConstructible<T>
27143 void more_generate_3() {
27145 generate_and_do_3(T());
27148 template <DefaultConstructible T>
27149 requires MoveConstructible<T>
27150 void something_and_generate_3() {
27161 virtual ~Abstract();
27162 virtual void foo() = 0; // abstract type
27163 Abstract(Abstract&&){} // MoveConstructible
27164 Abstract(){} // DefaultConstructible
27168 // The restricted template *accepts* the argument, but
27169 // causes a deep instantiation error in the internal function
27170 // generate_and_do_3:
27171 something_and_generate_3<Abstract>();
27173 </pre></blockquote>
27176 The proposed stricter constraint does not minimize the aim to
27177 support more general containers for which <tt>ObjectType</tt> would be
27178 sufficient. If such an extended container (lets assume it's still a
27179 class template) provides a constructor that accepts an <tt>initializer_list</tt>
27180 only <em>this</em> constructor would need to be restricted on <tt>ValueType</tt>:
27183 <blockquote><pre>template<ObjectType T>
27184 class ExtContainer {
27186 requires ValueType<T>
27187 ExtContainer(std::initializer_list<T>);
27190 </pre></blockquote>
27197 Move to Tentatively Ready.
27206 Need to look at again without concepts.
27211 <p><b>Proposed resolution:</b></p>
27214 In 18.9 [support.initlist]/p.1 replace in "header <tt><initializer_list></tt> synopsis"
27215 the constraint "<tt>ObjectType</tt>" in the template parameter list by the
27216 constraint "<tt>ValueType</tt>".
27226 <h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
27227 <p><b>Section:</b> X [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
27228 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
27229 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
27230 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
27231 <p><b>Discussion:</b></p>
27233 <p><b>Addresses US 90</b></p>
27236 The deleted copy-assignment operators for the atomic types are not
27237 marked as volatile in N2723, whereas the assignment operators from the
27238 associated non-atomic types are. e.g.
27240 <blockquote><pre>atomic_bool& operator=(atomic_bool const&) = delete;
27241 atomic_bool& operator=(bool) volatile;
27242 </pre></blockquote>
27245 This leads to ambiguity when assigning a non-atomic value to a
27246 non-volatile instance of an atomic type:
27248 <blockquote><pre>atomic_bool b;
27250 </pre></blockquote>
27253 Both assignment operators require a standard conversions: the
27254 copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
27255 conversion constructor to convert <tt>false</tt> to an instance of
27256 <tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
27257 use the assignment from a plain <tt>bool</tt>.
27261 This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied.
27269 Move to open. Assign to Lawrence. Related to US 90 comment.
27273 2009-08-17 Handled by
27274 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
27279 2009-10 Santa Cruz:
27284 NAD Editorial. Solved by
27285 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
27290 <p><b>Proposed resolution:</b></p>
27292 Add volatile qualification to the deleted copy-assignment operator of
27293 all the atomic types:
27296 <blockquote><pre>atomic_bool& operator=(atomic_bool const&) <ins>volatile</ins> = delete;
27297 atomic_itype& operator=(atomic_itype const&) <ins>volatile</ins> = delete;
27298 </pre></blockquote>
27304 This will mean that the deleted copy-assignment operator will require
27305 <i>two</i> conversions in the above example, and thus be a worse match than
27306 the assignment from plain <tt>bool</tt>.
27314 <h3><a name="910"></a>910. Effects of MoveAssignable</h3>
27315 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
27316 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2010-10-29</p>
27317 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
27318 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
27319 <p><b>Discussion:</b></p>
27320 <p><b>Addresses UK 150</b></p>
27323 The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
27324 concept, given in paragraph 7 is:
27327 <blockquote><pre>result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&>
27331 <i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
27332 <tt>rv</tt> before the assignment. [<i>Note:</i> there is no
27333 requirement on the value of <tt>rv</tt> after the assignment. <i>--end note</i>]
27338 The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
27339 probably due to a cut&paste from <tt>MoveConstructible</tt>. Moreover, the
27340 discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
27341 and might not reflect the user expectations. An implementation of the
27342 move assignment that just calls <tt>swap()</tt> would always fulfill the
27343 postcondition as stated, but might have surprising side-effects in case
27344 the source rvalue refers to an object that is not going to be
27345 immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a> for another example. Due to
27346 the sometimes intangible nature of the "user expectation", it seems
27347 difficult to have precise normative wording that could cover all cases
27348 without introducing unnecessary restrictions. However a non-normative
27349 clarification could be a very helpful warning sign that swapping is not
27350 always the correct thing to do.
27354 2009-05-09 Alisdair adds:
27360 Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
27363 The post-conditions after assignment are at a minimum that the object
27364 referenced by rv must be safely destructible, and the transaction should not
27365 leak resources. Ideally it should be possible to simply assign rv a new
27366 valid state after the call without invoking undefined behaviour, but any
27367 other use of the referenced object would depend upon additional guarantees
27373 2009-05-09 Howard adds:
27379 The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
27380 a valid object. Not one in a singular state. If, for example, the moved from
27381 object is a <tt>vector</tt>, one should be able to do anything on that moved-from
27382 <tt>vector</tt> that you can do with any other <tt>vector</tt>. However you would
27383 first have to query it to find out what its current state is. E.g. it might have <tt>capacity</tt>,
27384 it might not. It might have a non-zero <tt>size</tt>, it might not. But regardless,
27385 you can <tt>push_back</tt> on to it if you want.
27389 That being said, most standard code is now conceptized. That is, the concepts
27390 list the only operations that can be done with templated types - whether or not
27391 the values have been moved from.
27395 Here is user-written code which must be allowed to be legal:
27397 <blockquote><pre>#include <vector>
27398 #include <cstdio>
27400 template <class Allocator>
27402 inspect(std::vector<double, Allocator>&& v)
27404 std::vector<double, Allocator> result(move(v));
27405 std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
27406 std::printf("The contents of the vector are:\n");
27407 typedef typename std::vector<double, Allocator>::iterator I;
27408 for (I i = v.begin(), e = v.end(); i != e; ++i)
27409 printf("%f\n", *i);
27414 std::vector<double> v1(100, 5.5);
27417 </pre></blockquote>
27420 The above program does not treat the moved-from <tt>vector</tt> as singular. It
27421 only treats it as a <tt>vector</tt> with an unknown value.
27424 I believe the current proposed wording is consistent with my view on this.
27433 We agree that the proposed resolution
27434 is an improvement over the current wording.
27443 Need to look at again without concepts.
27452 Walter will consult with Dave and Doug.
27456 2009-10 Santa Cruz:
27461 We believe this is handled by the resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>,
27462 but there is to much going on in this area to be sure. Defer for now.
27466 2010-01-23 Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
27467 Rationale added below.
27472 <p><b>Rationale:</b></p>
27474 The current <tt>MoveAssignable</tt> requirements say everything that can be said
27475 in general. Each std-defined type has a more detailed specification of move
27480 <p><b>Proposed resolution:</b></p>
27482 In [concept.copymove], replace the postcondition in paragraph 7 with:
27486 <i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
27487 assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
27488 assignment, but the
27489 effect should be unsurprising to the user even in case <tt>rv</tt> is not
27490 immediately destroyed. This may require that resources previously owned
27491 by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
27499 <h3><a name="912"></a>912. Array swap needs to be conceptualized</h3>
27500 <p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
27501 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-01 <b>Last modified:</b> 2010-10-29</p>
27502 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
27503 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
27504 <p><b>Discussion:</b></p>
27506 With the adaption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>
27507 we have a new algorithm <tt>swap</tt> for C-arrays, which needs to be conceptualized.
27511 Post Summit Daniel adds:
27516 Recommend as NAD Editorial: The changes have already been applied to the WP
27517 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
27525 Move to NAD; the changes have already been made.
27529 <p><b>Proposed resolution:</b></p>
27531 Replace in 25.3.3 [alg.swap] before p. 3 until p. 4 by
27534 <blockquote><pre>template <<del>class</del> <ins>ValueType</ins> T, size_t N>
27535 <ins>requires Swappable<T></ins>
27536 void swap(T (&a)[N], T (&b)[N]);
27540 <del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del>
27543 <i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt>
27554 <h3><a name="913"></a>913. Superfluous requirements for replace algorithms</h3>
27555 <p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
27556 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2010-10-29</p>
27557 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
27558 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
27559 <p><b>Discussion:</b></p>
27561 (A) 25.3.5 [alg.replace]/1:
27565 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.
27569 (B) 25.3.5 [alg.replace]/4:
27573 <i>Requires:</i> The results of the expressions <tt>*first</tt> and <tt>new_value</tt> shall
27574 be writable to the result output iterator.[..]
27578 Since conceptualization, the quoted content of these clauses is covered
27579 by the existing requirements
27583 (A) <tt>OutputIterator<Iter, const T&></tt>
27591 (B) <tt>OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&></tt>
27595 resp, and thus should be removed.
27604 We agree with the proposed resolution.
27607 Move to Tentatively Ready.
27612 <p><b>Proposed resolution:</b></p>
27616 Remove 25.3.5 [alg.replace]/1.
27618 <blockquote><pre>template<ForwardIterator Iter, class T>
27619 requires OutputIterator<Iter, Iter::reference>
27620 && OutputIterator<Iter, const T&>
27621 && HasEqualTo<Iter::value_type, T>
27622 void replace(Iter first, Iter last,
27623 const T& old_value, const T& new_value);
27625 template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
27626 requires OutputIterator<Iter, Iter::reference>
27627 && OutputIterator<Iter, const T&>
27628 && CopyConstructible<Pred>
27629 void replace_if(Iter first, Iter last,
27630 Pred pred, const T& new_value);
27633 <del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del>
27639 25.3.5 [alg.replace]/4: Remove the sentence "The results of the
27640 expressions <tt>*first</tt> and
27641 <tt>new_value</tt> shall be writable to the result output iterator.".
27643 <blockquote><pre>template<InputIterator InIter, typename OutIter, class T>
27644 requires OutputIterator<OutIter, InIter::reference>
27645 && OutputIterator<OutIter, const T&>
27646 && HasEqualTo<InIter::value_type, T>
27647 OutIter replace_copy(InIter first, InIter last,
27649 const T& old_value, const T& new_value);
27651 template<InputIterator InIter, typename OutIter,
27652 Predicate<auto, InIter::value_type> Pred, class T>
27653 requires OutputIterator<OutIter, InIter::reference>
27654 && OutputIterator<OutIter, const T&>
27655 && CopyConstructible<Pred>
27656 OutIter replace_copy_if(InIter first, InIter last,
27658 Pred pred, const T& new_value);
27661 4 <i>Requires:</i> <del>The results of the expressions <tt>*first</tt> and
27662 <tt>new_value</tt> shall be writable to the <tt>result</tt> output
27663 iterator.</del> The ranges <tt>[first,last)</tt> and <tt>[result,result +
27664 (last - first))</tt> shall not overlap.
27675 <h3><a name="914"></a>914. Superfluous requirement for unique</h3>
27676 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
27677 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2010-10-29</p>
27678 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
27679 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
27680 <p><b>Discussion:</b></p>
27682 25.3.9 [alg.unique]/2: "Requires: The comparison function shall be an
27683 equivalence relation."
27687 The essence of this is already covered by the given requirement
27690 <blockquote><pre>EquivalenceRelation<auto, Iter::value_type> Pred
27691 </pre></blockquote>
27694 and should thus be removed.
27702 We agree with the proposed resolution.
27703 Move to Tentatively Ready.
27707 <p><b>Proposed resolution:</b></p>
27709 Remove 25.3.9 [alg.unique]/2
27712 <blockquote><pre>template<ForwardIterator Iter>
27713 requires OutputIterator<Iter, Iter::reference>
27714 && EqualityComparable<Iter::value_type>
27715 Iter unique(Iter first, Iter last);
27717 template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
27718 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
27719 && CopyConstructible<Pred>
27720 Iter unique(Iter first, Iter last,
27725 1 <i>Effects:</i> ...
27728 <del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del>
27738 <h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
27739 <tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&</tt></h3>
27740 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
27741 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2010-10-29</p>
27742 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
27743 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
27744 <p><b>Discussion:</b></p>
27746 It seems that the proposed changes for
27747 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
27748 were not clear enough in
27753 25.4.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
27754 type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
27755 <tt>pair<const T&, const T&></tt>,
27756 which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
27757 a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&</tt>.
27758 Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
27759 problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
27767 We agree with the proposed resolution.
27768 Move to Tentatively Ready.
27777 Moved from Tentatively Ready to Open only because the wording needs to be
27778 tweaked for concepts removal.
27782 2009-08-18 Daniel adds:
27787 Recommend NAD since the proposed changes have already been performed
27788 as part of editorial work of
27789 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
27793 2009-10 Santa Cruz:
27798 Can't find initializer_list form of minmax anymore, only variadic
27799 version. Seems like we had an editing clash with concepts. Leave Open,
27800 at least until editorial issues resolved. Bring this to Editor's
27805 2010 Pittsburgh: Pete to reapply
27806 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>.
27812 <p><b>Rationale:</b></p>
27813 Solved by reapplying
27814 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>.
27817 <p><b>Proposed resolution:</b></p>
27821 In 25 [algorithms]/2, header <tt><algorithm></tt> synopsis change as indicated:
27824 <blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
27825 <ins>requires CopyConstructible<T></ins>
27826 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
27827 minmax(initializer_list<T> t);
27829 template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
27830 <ins>requires CopyConstructible<T></ins>
27831 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
27832 minmax(initializer_list<T> t, Compare comp);
27833 </pre></blockquote>
27837 In 25.4.7 [alg.min.max] change as indicated (Begin: Just before p.20):
27839 <blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
27840 <ins>requires CopyConstructible<T></ins>
27841 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
27842 minmax(initializer_list<T> t);
27846 <del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
27847 <tt>CopyConstructible</tt>.</del>
27850 -21- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
27851 </del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
27852 smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
27857 <pre>template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
27858 <ins>requires CopyConstructible<T></ins>
27859 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
27860 minmax(initializer_list<T> t, Compare comp);
27865 <del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
27868 -25- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
27869 </del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
27870 smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
27883 <h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
27884 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
27885 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2010-10-29</p>
27886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
27887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
27888 <p><b>Discussion:</b></p>
27889 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>.</b></p>
27892 The current WP provides the following assignment operators for <tt>pair</tt>
27893 in 20.3.5 [pairs]/1:
27898 <pre>template<class U , class V>
27899 requires HasAssign<T1, const U&> && HasAssign<T2, const V&>
27900 pair& operator=(const pair<U , V>& p);
27904 <pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
27908 <pre>template<class U , class V>
27909 requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type>
27910 pair& operator=(pair<U , V>&& p);
27916 It seems that the functionality of (2) is completely covered by (3), therefore
27917 (2) should be removed.
27926 Bill believes the extra assignment operators are necessary for resolving
27927 ambiguities, but that does not mean it needs to be part of the specification.
27931 We recommend this be looked at in the context of the ongoing work
27932 related to the pair templates.
27942 Leave this open pending the removal of concepts from the WD.
27946 2009-10 Santa Cruz:
27951 Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
27956 <p><b>Proposed resolution:</b></p>
27960 In 20.3.5 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
27963 <blockquote><pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
27964 </pre></blockquote>
27978 <h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
27979 <p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
27980 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2010-10-29</p>
27981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
27982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
27983 <p><b>Discussion:</b></p>
27984 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>.</b></p>
27986 N2770 (and thus now the WP) removed the
27987 non-template move-assignment operator from tuple's class definition,
27988 but the latter individual member description does still provide this
27989 operator. Is this (a) an oversight and can it (b) be solved as part of an
27994 Post Summit Daniel provided wording.
28004 We believe that the proposed resolution's part 1 is editorial.
28007 Regarding part 2, we either remove the specification as proposed,
28008 or else add back the declaration to which the specification refers.
28009 Alisdair and Bill prefer the latter.
28010 It is not immediately obvious whether the function is intended to be present.
28013 We recommend that the Project Editor restore the missing declaration
28014 and that we keep part 2 of the issue alive.
28027 Leave this open pending the removal of concepts from the WD.
28031 2009-10 Santa Cruz:
28036 Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
28041 <p><b>Proposed resolution:</b></p>
28045 In 20.4.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
28046 change as indicated:
28049 This fixes an editorial loss between N2798 to N2800
28052 <blockquote><pre>template <class... UTypes>
28053 requires HasAssign<Types, const UTypes&>...
28054 <ins>tuple& operator=(const pair<UTypes...>&);</ins>
28056 template <class... UTypes>
28057 requires HasAssign<Types, RvalueOf<UTypes>::type>...
28058 <ins>tuple& operator=(pair<UTypes...>&&);</ins>
28059 </pre></blockquote>
28063 In 20.4.2.1 [tuple.cnstr], starting just before p. 11 please remove
28067 <blockquote><pre><del>requires MoveAssignable<Types>... tuple& operator=(tuple&& u);</del>
28071 <del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
28072 element of <tt>*this</tt>.</del>
28075 <del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
28087 <h3><a name="918"></a>918. Swap for tuple needs to be conceptualized</h3>
28088 <p><b>Section:</b> 20.4.2.3 [tuple.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
28089 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2010-10-29</p>
28090 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
28091 <p><b>Discussion:</b></p>
28093 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a> was accepted after <tt>tuple</tt> had been conceptualized,
28094 therefore this step needs to be completed.
28098 Post Summit Daniel adds
28103 This is now NAD Editorial (addressed by
28104 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>)
28105 except for item 3 in the proposed wording.
28109 2009-05-01 Daniel adds:
28114 As of the recent WP
28115 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>),
28116 this issue is now completely covered by editorial
28117 changes (including the third bullet), therefore I unconditionally recommend
28127 We observed that all the proposed changes have already been applied to the
28128 Working Draft, rendering this issue moot.
28137 <p><b>Proposed resolution:</b></p>
28141 In both 20.4.1 [tuple.general]/2 and 20.4.2.9 [tuple.special] change
28144 <blockquote><pre>template <<del>class</del> <ins>Swappable</ins>... Types>
28145 void swap(tuple<Types...>& x, tuple<Types...>& y);
28146 </pre></blockquote>
28152 In 20.4.2 [tuple.tuple], class <tt>tuple</tt> definition and in
28153 20.4.2.3 [tuple.swap], change
28156 <blockquote><pre><ins>requires Swappable<Types>...</ins>void swap(tuple&);
28157 </pre></blockquote>
28163 In 20.4.2.3 [tuple.swap] remove the current requires-clause, which says:
28167 <del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del>
28179 <h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
28180 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
28181 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2010-10-29</p>
28182 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
28183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
28184 <p><b>Discussion:</b></p>
28186 The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
28187 defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
28190 <blockquote><pre>requires EqualityComparable<T> void remove(const T& value);
28191 </pre></blockquote>
28194 are asymmetric to their predicate variants (which only require
28195 <tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
28196 remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
28198 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
28199 implies that <tt>EqualityComparable</tt> should
28200 be the intended requirement.
28209 We agree with the proposed resolution,
28210 but would like additional input from concepts experts.
28218 2009-07-21 Alisdair adds:
28223 Current rationale and wording for this issue is built around concepts. I
28224 suggest the issue reverts to Open status. I believe there is enough of
28225 an issue to review after concepts are removed from the WP to re-examine
28226 the issue in Santa Cruz, rather than resolve as NAD Concepts.
28230 2009-10-10 Daniel adds:
28235 Recommend NAD: The concept-free wording as of
28236 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
28238 over-specified requirement
28239 <tt>EqualityComparable</tt> for the remove function that uses <tt>==</tt>. In fact, now
28240 the same test conditions exists
28241 as for the free algorithm <tt>remove</tt> (25.3.8 [alg.remove]). The error was
28242 introduced in the process of conceptifying.
28246 2009-10 Santa Cruz:
28251 NAD, solved by the removal of concepts.
28256 <p><b>Proposed resolution:</b></p>
28260 Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
28263 <blockquote><pre>requires <del>EqualityComparable<T></del> <ins>HasEqualTo<T, T></ins> void remove(const T& value);
28264 </pre></blockquote>
28274 <h3><a name="923"></a>923. atomics with floating-point </h3>
28275 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
28276 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2010-10-29</p>
28277 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
28278 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
28279 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
28280 <p><b>Discussion:</b></p>
28282 Right now, C++0x doesn't have <tt>atomic<float></tt>. We're thinking of adding
28283 the words to support it for TR2 (note: that would be slightly
28284 post-C++0x). If we need it, we could probably add the words.
28287 <b>Proposed resolutions:</b> Using <tt>atomic<FP>::compare_exchange</tt> (weak or
28288 strong) should be either:
28301 I propose Option 1 for C++0x for expediency. If someone wants to argue
28302 for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
28303 to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
28312 Move to open. Blocked until concepts for atomics are addressed.
28316 Post Summit Anthony adds:
28322 Recommend NAD. C++0x does have <tt>std::atomic<float></tt>, and both
28323 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
28324 this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
28329 [<i>Note:</i> The effect of the compare-and-exchange operations is
28331 <blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
28334 *expected = *object;
28335 </pre></blockquote>
28338 This may result in failed comparisons for values that compare equal if
28339 the underlying type has padding bits or alternate representations of
28340 the same value. <i>-- end note</i>]
28347 2009-10 Santa Cruz:
28352 NAD Editorial. Solved by
28353 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28358 <p><b>Proposed resolution:</b></p>
28360 Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
28365 [<i>Note:</i> The effect of the compare-and-exchange operations is
28367 <blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
28370 *expected = *object;
28371 </pre></blockquote>
28374 This may result in failed comparisons for values that compare equal if
28375 the underlying type has padding bits or alternate representations of
28376 the same value.</ins> <i>-- end note</i>]
28386 <h3><a name="924"></a>924. structs with internal padding</h3>
28387 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
28388 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2010-10-29</p>
28389 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
28390 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
28391 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
28392 <p><b>Discussion:</b></p>
28394 Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
28395 padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
28396 compiler work to ignore padding for comparison purposes.
28399 Note that this isn't a problem for structs with no padding, and we do
28400 already have one portable way to ensure that there is no padding that
28401 covers the key use cases: Have elements be the same type. I suspect that
28402 the greatest need is for a structure of two pointers, which has no
28403 padding problem. I suspect the second need is a structure of a pointer
28404 and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
28408 Related but separable issue: For unused bitfields, or other unused
28409 fields for that matter, we should probably say it's the programmer's
28410 responsibility to set them to zero or otherwise ensure they'll be
28411 ignored by <tt>memcmp</tt>.
28415 <b>Proposed resolutions:</b> Using
28416 <tt>atomic<struct-with-padding>::compare_exchange_strong</tt> should be either:
28429 I propose Option 1 for C++0x for expediency, though I'm not sure how to
28430 say it. I would be happy with Option 2, which I believe would mean that
28431 <tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
28432 bytes, or something equivalent such as always zeroing out padding when
28433 loading/storing/comparing. (Either implementation might require compiler
28443 Move to open. Blocked until concepts for atomics are addressed.
28447 Post Summit Anthony adds:
28452 The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a> should resolve this issue as well.
28456 2009-10 Santa Cruz:
28461 NAD Editorial. Solved by
28462 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28467 <p><b>Proposed resolution:</b></p>
28476 <h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
28477 <p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
28478 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19 <b>Last modified:</b> 2010-10-29</p>
28479 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
28480 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
28481 <p><b>Discussion:</b></p>
28482 <p><b>Addresses UK 313</b></p>
28485 There was an interesting issue raised over on comp.programming.threads
28486 today regarding the following example
28489 <blockquote><pre>// Thread 1:
28490 x.store(1, memory_order_relaxed); // SX
28491 atomic_thread_fence(memory_order_seq_cst); // F1
28492 y.store(1, memory_order_relaxed); // SY1
28493 atomic_thread_fence(memory_order_seq_cst); // F2
28494 r1 = y.load(memory_order_relaxed); // RY
28497 y.store(0, memory_order_relaxed); // SY2
28498 atomic_thread_fence(memory_order_seq_cst); // F3
28499 r2 = x.load(memory_order_relaxed); // RX
28500 </pre></blockquote>
28503 is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
28506 I think the intent is that this is not possible, but I am not sure the
28507 wording guarantees that. Here is my analysis:
28510 Since all the fences are SC, there must be a total order between them.
28511 <tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
28512 the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
28513 between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
28516 If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
28517 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
28521 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
28522 <tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
28523 its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
28524 and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
28525 <tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
28526 <tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
28527 <tt>A</tt> or a later modification of <tt>M</tt> in its modification
28532 In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
28533 fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
28534 so <tt>RX</tt> must see 1.
28537 If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
28538 <tt>F3</tt> can therefore be before or after <tt>F1</tt>.
28541 If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
28542 time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
28546 Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
28547 in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
28548 <tt>RX</tt> can see <tt>r2==0</tt>.
28551 We can apply 29.3 [atomics.order]p5 again. This time,
28552 <tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
28553 <tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
28554 the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
28555 modification order.
28558 Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
28559 observe the effects of <tt>SY1</tt> or a later modification of
28560 <tt>y</tt> in its modification order.
28563 In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
28564 that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
28568 We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
28569 <tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
28570 happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
28571 modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
28572 the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
28573 words are clear on that.
28577 Post Summit Hans adds:
28583 In my (Hans') view, our definition of fences will always be weaker than
28584 what particular hardware will guarantee. <tt>Memory_order_seq_cst</tt> fences
28585 inherently don't guarantee sequential consistency anyway, for good
28586 reasons (e.g. because they can't enforce a total order on stores).
28587 Hence I don't think the issue demonstrates a gross failure to achieve
28588 what we intended to achieve. The example in question is a bit esoteric.
28589 Hence, in my view, living with the status quo certainly wouldn't be a
28593 In any case, we should probably add text along the lines of the
28594 following between p5 and p6 in 29.3 [atomics.order]:
28597 [Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
28598 data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
28599 operations. Any use of weaker ordering will invalidate this guarantee
28600 unless extreme care is used. In particular, <tt>memory_order_seq_cst</tt> fences
28601 only ensure a total order for the fences themselves. They cannot, in
28602 general, be used to restore sequential consistency for atomic operations
28603 with weaker ordering specifications.]
28607 Also see thread beginning at c++std-lib-23271.
28613 Herve's correction:
28618 Minor point, and sorry for the knee jerk reaction: I admit to having
28619 no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
28620 has ingrained an automatic introspection on the use of "only". I
28625 [Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
28626 for . . . . In particular, <tt>memory_order_seq_cst</tt> fences ensure a
28627 total order only for . . .
28630 Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
28631 sequential consistency for a data-race-free program that uses
28632 exclusively <tt>memory_order_seq_cst</tt> operations.
28637 2009-10 Santa Cruz:
28642 NAD Editorial. Solved by
28643 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28648 <p><b>Proposed resolution:</b></p>
28650 Add a new paragraph after 29.3 [atomics.order]p5 that says
28654 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
28655 <tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
28656 are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
28657 that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
28658 before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
28659 then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
28668 <h3><a name="927"></a>927. <tt>Dereferenceable</tt> should be <tt>HasDereference</tt></h3>
28669 <p><b>Section:</b> X [allocator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
28670 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2010-10-29</p>
28671 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
28672 <p><b>Discussion:</b></p>
28674 X [allocator.concepts] contains a reference to a concept named
28675 <tt>Dereferenceable</tt>. No such concept exists.
28679 Daniel adds 2009-02-14:
28684 The proposal given in the paper
28685 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2829.pdf">N2829</a>
28686 would automatically resolve this issue.
28696 This particular set of changes has already been made.
28697 There are two related changes later on (and possibly also an earlier Example);
28698 these can be handled editorially.
28701 Move to NAD Editorial.
28706 <p><b>Proposed resolution:</b></p>
28708 Change all uses of the concept <tt>Dereferenceable</tt> to
28709 <tt>HasDereference</tt> in X [allocator.concepts].
28717 <h3><a name="928"></a>928. Wrong concepts used for <tt>tuple</tt>'s comparison operators</h3>
28718 <p><b>Section:</b> 20.4.2.7 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
28719 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2008-10-28 <b>Last modified:</b> 2010-10-29</p>
28720 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
28721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
28722 <p><b>Discussion:</b></p>
28724 In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator<</tt>
28728 <blockquote><pre>template<class... TTypes, class... UTypes>
28729 requires EqualityComparable<TTypes, UTypes>...
28730 bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
28731 </pre></blockquote>
28737 <blockquote><pre>template<class... TTypes, class... UTypes>
28738 requires LessThanComparable<TTypes, UTypes>...
28739 bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
28740 </pre></blockquote>
28743 But the concepts <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt> only take one
28744 parameter, not two. Also, even if <tt>LessThanComparable</tt> could take two
28745 parameters, the definition of <tt>tuple::operator<()</tt> should also require
28748 <blockquote><pre>LessThanComparable<UTypes, TTypes>... // (note the order)
28749 </pre></blockquote>
28752 since the algorithm for <tt>tuple::operator<</tt> is the following (pseudo-code)
28755 <blockquote><pre>for (size_t N = 0; N < sizeof...(TTypes); ++N) {
28756 if (get<N>(t) < get<N>(u) return true;
28757 else if ((get<N>(u) < get<N>(t)) return false;
28761 </pre></blockquote>
28764 Similar problems hold for <tt>tuples</tt>'s other comparison operators.
28773 Recommend Tentatively Ready.
28778 <p><b>Proposed resolution:</b></p>
28780 In 20.4.1 [tuple.general] and 20.4.2.7 [tuple.rel] change:
28783 <blockquote><pre>template<class... TTypes, class... UTypes>
28784 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
28785 bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&);
28787 template<class... TTypes, class... UTypes>
28788 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
28789 bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&);
28791 template<class... TTypes, class... UTypes>
28792 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
28793 bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);
28795 template<class... TTypes, class... UTypes>
28796 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
28797 bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&);
28799 template<class... TTypes, class... UTypes>
28800 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
28801 bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&);
28803 template<class... TTypes, class... UTypes>
28804 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
28805 bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&);
28806 </pre></blockquote>
28813 <h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
28814 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
28815 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17 <b>Last modified:</b> 2010-10-29</p>
28816 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
28817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
28818 <p><b>Discussion:</b></p>
28821 The Working Draft (N2798) allows access to the elements of
28822 <tt>std::array</tt> by its <tt>data()</tt> member function:
28827 <h5>23.2.1.4 array::data [array.data]</h5>
28829 const T *data() const;
28837 Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
28838 to a reference to a built-in array of the type of <tt>array::elems</tt>.
28839 And <tt>std::array</tt> provides no other way to get a reference to
28840 <tt>array::elems</tt>.
28841 This hampers the use of <tt>std::array</tt>, for example when trying to
28842 pass its data to a C style API function:
28845 <pre> // Some C style API function.
28846 void set_path( char (*)[MAX_PATH] );
28848 std::array<char,MAX_PATH> path;
28849 set_path( path.data() ); // error
28850 set_path( &(path.data()) ); // error
28854 Another example, trying to pass the array data to an instance of another
28858 <pre> // Represents a 3-D point in space.
28859 class three_d_point {
28861 explicit three_d_point(const double (&)[3]);
28864 const std::array<double,3> coordinates = { 0, 1, 2 };
28865 three_d_point point1( coordinates.data() ); // error.
28866 three_d_point point2( *(coordinates.data()) ); // error.
28870 A user might be tempted to use <tt>std::array::elems</tt> instead, but
28871 doing so isn't recommended, because <tt>std::array::elems</tt> is "for
28872 exposition only". Note that Boost.Array users might already use
28873 <tt>boost::array::elems</tt>, as its documentation doesn't explicitly
28874 state that <tt>boost::array::elems</tt> is for exposition only:
28875 http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
28878 I can think of three options to solve this issue:
28881 Remove the words "exposition only" from the definition of
28882 <tt>std::array::elems</tt>, as well as the note saying that "elems is
28883 shown for exposition only."
28885 Change the signature of <tt>std::array::data()</tt>, so that it would
28886 return a reference to the built-in array, instead of a pointer to its
28889 Add extra member functions, returning a reference to the built-in array.
28892 Lawrence Crowl wrote me that it might be better to leave
28893 <tt>std::array::elems</tt> "for exposition only", to allow alternate
28894 representations to allocate the array data dynamically. This might be
28895 of interest to the embedded community, having to deal with very limited
28899 The second option, changing the return type of
28900 <tt>std::array::data()</tt>, would break backward compatible to current
28901 Boost and TR1 implementations, as well as to the other contiguous
28902 container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
28903 For example, the following call to <tt>std::swap</tt> currently swap two
28904 locally declared pointers <tt>(data1, data2)</tt>, for any container
28905 type <tt>T</tt> that has a <tt>data()</tt> member function. When
28906 <tt>std::array::data()</tt> is changed to return a reference, the
28907 <tt>std::swap</tt> call may swap the container elements instead.
28910 <pre> template <typename T>
28911 void func(T& container1, T& container2)
28913 // Are data1 and data2 pointers or references?
28914 auto data1 = container1.data();
28915 auto data2 = container2.data();
28917 // Will this swap two local pointers, or all container elements?
28918 std::swap(data1, data2);
28923 The following concept is currently satisfied by all contiguous
28924 containers, but it no longer is for <tt>std::array</tt>, when
28925 <tt>array::data()</tt>
28926 is changed to return a reference (tested on ConceptGCC Alpha 7):
28929 <pre> auto concept ContiguousContainerConcept<typename T>
28931 typename value_type = typename T::value_type;
28932 const value_type * T::data() const;
28937 Still it's worth considering having <tt>std::array::data()</tt> return a
28938 reference, because it might be the most intuitive option, from a user's
28939 point of view. Nicolai Josuttis (who wrote <tt>boost::array</tt>)
28940 mailed me that he very much prefers this option.
28943 Note that for this option, the definition of <tt>data()</tt> would also
28944 need to be revised for zero-sized arrays, as its return type cannot be a
28945 reference to a zero-sized built-in array. Regarding zero-sized array,
28946 <tt>data()</tt> could throw an exception. Or there could be a partial
28947 specialization of <tt>std::array</tt> where <tt>data()</tt> returns
28948 <tt>T*</tt> or gets removed.
28951 Personally I prefer the third option, adding a new member function to
28952 <tt>std::array</tt>, overloaded for const and non-const access,
28953 returning a reference to the built-in array, to avoid those compatible
28954 issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
28955 which sounds intuitive to me. Note that <tt>boost::array</tt> already
28956 has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
28957 me that this one is only there for historical reasons. (Otherwise a name
28958 like <tt>std::array::native_array()</tt> or
28959 <tt>std::array::builtin_array()</tt> would also be fine with me.)
28960 According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
28961 to have <tt>c_array()</tt>, while it is still required to have
28962 <tt>data()</tt> functions.
28973 Alisdair: Don't like p4 suggesting implementation-defined behaviour.
28976 Walter: What about an explicit conversion operator, instead of adding
28977 the new member function?
28980 Alisdair: Noodling about:
28982 <blockquote><pre>template<size_t N, ValueType T>
28987 // fantasy code starts here
28989 // crazy decltype version for grins only
28990 //requires True<(N>0)>
28991 //explict operator decltype(elems) & () { return elems; }
28993 // conversion to lvalue ref
28994 requires True<(N>0)>
28995 explict operator T(&)[N] () & { return elems; }
28997 // conversion to const lvalue ref
28998 requires True<(N>0)>
28999 explict operator const T(&)[N] () const & { return elems; }
29001 // conversion to rvalue ref using ref qualifiers
29002 requires True<(N>0)>
29003 explict operator T(&&)[N] () && { return elems; }
29005 // fantasy code ends here
29007 explicit operator bool() { return true; }
29009 </pre></blockquote>
29012 This seems legal but odd. Jason Merrill says currently a CWG issue 613
29013 on the non-static data member that fixes the error that current G++
29014 gives for the non-explicit, non-conceptualized version of this. Verdict
29015 from human compiler: seems legal.
29018 Some grumbling about zero-sized arrays being allowed and supported.
29021 Walter: Would this address the issue? Are we inclined to go this route?
29024 Alan: What would usage look like?
29026 <blockquote><pre>// 3-d point in space
29027 struct three_d_point
29029 explicit three_d_point(const double (&)[3]);
29032 void sink(double*);
29034 const std::array<double, 3> coordinates = { 0, 1, 2 };
29035 three_d_point point1( coordinates.data() ); //error
29036 three_d_point point2( *(coordinates.data()) ); // error
29037 three_d_point point3( coordinates ); // yay!
29039 sink(cooridinates); // error, no conversion
29040 </pre></blockquote>
29043 Recommended Open with new wording. Take the required clause and add the
29044 explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
29045 <tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
29046 <tt>decltype</tt> is specially clever.
29052 Post Summit, further discussion in the thread starting with c++std-lib-23215.
29057 2009-07 post-Frankfurt (Saturday afternoon group):
29063 The idea to resolve the issue by adding explicit conversion operators
29064 was abandoned, because it would be inconvenient to use, especially when
29065 passing the array to a template function, as mentioned by Daniel. So we
29066 reconsidered the original proposed resolution, which appeared
29067 acceptable, except for its proposed changes to 23.3.1.7 [array.zero], which
29068 allowed <tt>c_array_type</tt> and <tt>c_array()</tt> to be absent for a zero-sized array.
29069 Alisdair argued that such wording would disallow certain generic use
29070 cases. New wording for 23.3.1.7 [array.zero] was agreed upon (Howard: and
29071 is reflected in the proposed resolution).
29079 2009-07-31 Alisdair adds:
29085 I will be unhappy voting the proposed resolution for 930 past review
29086 until we have implementation experience with reference qualifiers.
29087 Specifically, I want to understand the impact of the missing overload
29088 for <tt>const &&</tt> (if any.)
29092 If we think the issue is important enough it might be worthwhile
29093 stripping the ref qualifiers for easy progress next meeting, and opening
29094 yet another issue to put them back with experience.
29098 Recommend deferring any decision on splitting the issue until we get LWG
29099 feedback next meeting - I may be the lone dissenting voice if others are
29100 prepared to proceed without it.
29105 2009-10 Santa Cruz:
29110 Mark as NAD. There was not enough consensus that this was sufficiently
29111 useful. There are known other ways to do this, such as small inline
29112 conversion functions.
29117 <p><b>Proposed resolution:</b></p>
29119 Add to the template definition of array, 23.3.1 [array]/3:
29124 typedef T c_array_type[N];
29125 c_array_type & c_array() &;
29126 c_array_type && c_array() &&;
29127 const c_array_type & c_array() const &;
29133 Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
29137 <h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
29139 c_array_type & c_array() &;
29140 c_array_type && c_array() &&;
29141 const c_array_type & c_array() const &;
29145 <ins><i>Returns:</i> <tt>elems</tt>.</ins>
29154 Change Zero sized arrays 23.3.1.7 [array.zero]:
29162 The type <tt>c_array_type</tt> is unspecified for a zero-sized array.
29166 -3- The effect of calling <ins><tt>c_array()</tt>,</ins> <tt>front()</tt><ins>,</ins> or
29167 <tt>back()</tt> for a zero-sized array is implementation defined.
29177 <h3><a name="933"></a>933. Unique_ptr defect</h3>
29178 <p><b>Section:</b> 20.9.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
29179 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27 <b>Last modified:</b> 2010-10-29</p>
29180 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
29181 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
29182 <p><b>Discussion:</b></p>
29184 If we are supporting stateful deleters, we need an overload for
29185 <tt>reset</tt> that
29186 takes a deleter as well.
29189 <blockquote><pre>void reset( pointer p, deleter_type d);
29190 </pre></blockquote>
29193 We probably need two overloads to support move-only deleters, and
29195 sounds uncomfortably like the two constructors I have been ignoring
29206 Howard comments that we have the functionality via move-assigment.
29214 2009-10 Santa Cruz:
29219 Mark as NAD Future.
29224 <p><b>Proposed resolution:</b></p>
29233 <h3><a name="935"></a>935. clock error handling needs to be specified</h3>
29234 <p><b>Section:</b> 20.11.5 [time.clock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
29235 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24 <b>Last modified:</b> 2010-10-29</p>
29236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
29237 <p><b>Discussion:</b></p>
29239 Each of the three clocks specified in Clocks 20.11.5 [time.clock]
29240 provides the member function:
29243 <blockquote><pre>static time_point now();
29244 </pre></blockquote>
29247 The semantics specified by Clock requirements 20.11.1 [time.clock.req]
29248 make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
29249 or an implementation-defined exception (17.6.4.12 [res.on.exception.handling]
29254 Some implementations of these functions on POSIX, Windows, and
29255 presumably on other operating systems, may fail in ways only detectable
29256 at runtime. Some failures on Windows are due to supporting chipset
29257 errata and can even occur after successful calls to a clock's <tt>now()</tt>
29262 These functions are used in cases where exceptions are not appropriate
29263 or where the specifics of the exception or cause of error need to be
29264 available to the user. See
29265 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
29266 <i>Library Support for hybrid error
29267 handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
29268 the interface of now is required.
29272 The proposed resolution has been implemented in the Boost version of the
29273 chrono library. No problems were encountered.
29282 We recommend this issue be deferred until the next Committee Draft
29283 has been issued and the prerequisite paper has been accepted.
29291 2009-10 Santa Cruz:
29296 Mark as NAD future. Too late to make this change without having already
29297 accepted the hybrid error handling proposal.
29302 <p><b>Proposed resolution:</b></p>
29304 Accept the proposed wording of
29305 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
29306 <i>Library Support for hybrid error handling (Rev 1)</i>.
29310 Change Clock requirements 20.11.1 [time.clock.req] as indicated:
29315 -2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
29316 <tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call
29317 returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
29318 both of these calls happen before <tt>C1::time_point::max()</tt>.
29319 <ins><tt>ec</tt> denotes an object of type <tt>error_code</tt>
29320 (19.5.2.1 [syserr.errcode.overview]).</ins>
29324 <caption>Table 55 -- Clock requirements</caption>
29326 <th>Expression</th><th>Return type</th><th>Operational semantics</th>
29336 <td><tt>C1::now()</tt></td>
29337 <td><tt>C1::time_point</tt></td>
29338 <td>Returns a <tt>time_point</tt> object representing the current point in time.
29343 <td><tt><ins>C1::now(ec)</ins></tt></td>
29344 <td><tt><ins>C1::time_point</ins></tt></td>
29345 <td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
29352 Change Class system_clock 20.11.5.1 [time.clock.system] as indicated:
29355 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
29356 </pre></blockquote>
29359 Change Class monotonic_clock X [time.clock.monotonic] as indicated:
29362 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
29363 </pre></blockquote>
29366 Change Class high_resolution_clock 20.11.5.3 [time.clock.hires] as indicated:
29369 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
29370 </pre></blockquote>
29378 <h3><a name="936"></a>936. Mutex type overspecified</h3>
29379 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
29380 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2010-10-29</p>
29381 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
29382 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
29383 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a></p>
29384 <p><b>Discussion:</b></p>
29389 30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
29390 a "Mutex type". A Mutex type can be used as the template argument for
29391 the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
29392 <tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
29393 formal meaning in 30.4.2 [thread.lock]) and, although the WD doesn't quite say
29394 so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
29398 The requirements for a Mutex type include:
29403 <tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
29406 <tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
29409 <tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
29414 Also, a Mutex type "shall not be copyable nor movable".
29418 The latter requirement seems completely irrelevant, and the three
29419 requirements on return types are tighter than they need to be. For
29420 example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
29421 type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
29422 try to copy objects of that type. That's a constraint on locks, not on
29423 mutexes. Similarly, the requirements for <tt>void</tt> return types are
29424 unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
29425 returned value. And with the return type of <tt>bool</tt>, the requirement should
29426 be that the return type is convertible to <tt>bool</tt>.
29436 Move to open. Related to conceptualization and should probably be tackled as part of that.
29440 The intention is not only to place a constraint on what types such as
29441 <tt>lock_guard</tt> may do with mutex types, but on what any code, including user
29442 code, may do with mutex types. Thus the constraints as they are apply to
29443 the mutex types themselves, not the current users of mutex types in the
29447 This is a low priority issue; the wording as it is may be overly
29448 restrictive but this may not be a real issue.
29454 Post Summit Anthony adds:
29460 Section 30.4.1 [thread.mutex.requirements] conflates the
29461 requirements on a generic Mutex type (including user-supplied mutexes)
29462 with the requirements placed on the standard-supplied mutex types in an
29463 attempt to group everything together and save space.
29466 When applying concepts to chapter 30, I suggest that the concepts
29467 <tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
29468 *use* of a mutex type as required by
29469 <tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
29470 relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
29471 <tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
29472 <tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
29473 and should be rephrased as such.
29479 <p><b>Proposed resolution:</b></p>
29488 <h3><a name="937"></a>937. Atomics for standard typedef types</h3>
29489 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
29490 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2010-10-29</p>
29491 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
29492 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
29493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
29494 <p><b>Discussion:</b></p>
29496 <p><b>Addresses US 89</b></p>
29500 The types in the table "Atomics for standard typedef types" should be
29501 typedefs, not classes. These semantics are necessary for compatibility
29506 Change the classes to typedefs.
29511 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
29512 specified different requirements for atomic analogs of fundamental
29513 integer types (such as <tt>atomic_int</tt>) and for atomic analogs of <tt><cstdint></tt>
29514 typedefs (such as <tt>atomic_size_t</tt>). Specifically, <tt>atomic_int</tt> et al. were
29515 specified to be distinct classes, whereas <tt>atomic_size_t</tt> et al. were
29516 specified to be typedefs. Unfortunately, in applying
29517 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
29518 to the WD, that distinction was erased, and the atomic analog of every <tt><cstdint></tt>
29519 typedef is required to be a distinct class.
29523 It shouldn't be required that the atomic analog of every <tt><cstdint></tt>
29524 typedef be a typedef for some fundamental integer type. After all,
29525 <tt><cstdint></tt> is supposed to provide standard names for extended integer
29526 types. So there was a problem in
29527 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>,
29528 which certainly could have been
29529 interpreted to require that. But the status quo in the WD is even worse,
29530 because it's unambiguously wrong.
29534 What is needed are words to require the existence of a bunch of type
29535 names, without specifying whether they are class names or typedef names.
29545 Change status to NAD, editorial. See US 89 comment notes above.
29548 Direct the editor to turn the types into typedefs as proposed in the
29549 comment. Paper approved by committee used typedefs, this appears to have
29550 been introduced as an editorial change. Rationale: for compatibility
29556 <p><b>Proposed resolution:</b></p>
29565 <h3><a name="940"></a>940. <tt>std::distance</tt></h3>
29566 <p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
29567 <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14 <b>Last modified:</b> 2010-10-29</p>
29568 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
29569 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
29570 <p><b>Discussion:</b></p>
29572 <p><b>Addresses UK 270</b></p>
29575 Regarding the <tt>std::distance</tt> - function, 24.4.4 [iterator.operations]
29580 number of increments or decrements needed to get from first to last.
29583 This sentence is completely silent about the sign of the return value.
29584 24.4.4 [iterator.operations] / 1 gives more information about the
29585 underlying operations, but
29586 again no inferences about the sign can be made.
29587 Strictly speaking, that is taking that sentence literally, I think this
29588 sentence even implies a positive return value in all cases, as the
29589 number of increments or decrements is clearly a ratio scale variable,
29590 with a natural zero bound.
29593 Practically speaking, my implementations did what common sense and
29594 knowledge based on pointer arithmetic forecasts, namely a positive sign
29595 for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
29596 negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
29599 Here are my two questions:
29602 First, is that paragraph supposed to be interpreted in the way what I
29603 called 'common sense', that is negative sign for decrements ? I am
29604 fairly sure that's the supposed behavior, but a double-check here in
29605 this group can't hurt.
29608 Second, is the present wording (2003 standard version - no idea about
29609 the draft for the upcoming standard) worth an edit to make it a bit more
29610 sensible, to mention the sign of the return value explicitly ?
29620 My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
29621 issue report, but it seems that current normative wording is in
29622 contradiction to that resolution:
29627 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
29628 24.4.4 [iterator.operations]/ p.4 says:
29632 <i>Effects:</i> Returns the number of increments or decrements needed to get
29633 from <tt>first</tt> to <tt>last</tt>.
29637 IMO the part " or decrements" is in contradiction to p. 5 which says
29641 <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
29645 because "reachable" is defined in X [iterator.concepts]/7 as
29649 An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
29651 sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
29655 Here is wording that would be consistent with this definition of "reachable":
29659 Change 24.4.4 [iterator.operations] p4 as follows:
29663 <i>Effects:</i> Returns the number of increments <del>or decrements</del>
29664 needed to get from <tt>first</tt> to <tt>last</tt>.
29670 Thomas adds more discussion and an alternative view point
29671 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
29680 The proposed wording below was verbally agreed to. Howard provided.
29689 Pete reports that a recent similar change has been made
29690 for the <tt>advance()</tt> function.
29693 We agree with the proposed resolution.
29694 Move to Tentatively Ready.
29704 Moved from Tentatively Ready to Open only because the wording needs to be
29705 tweaked for concepts removal.
29714 Leave Open pending arrival of a post-Concepts WD.
29718 2009-10-14 Daniel provided de-conceptified wording.
29723 2009-10 Santa Cruz:
29728 Move to Ready, replacing the Effects clause in the proposed wording with
29729 "If InputIterator meets the requirements of random access iterator then
29730 returns (last - first), otherwise returns the number of increments
29731 needed to get from first to list.".
29740 Moved to NAD Editorial. Rationale added below.
29745 <p><b>Rationale:</b></p>
29751 <p><b>Proposed resolution:</b></p>
29755 Change 24.2.7 [random.access.iterators], Table 105 as indicated [This change is not
29756 essential but it simplifies the specification] for the row with
29757 expression "<tt>b - a</tt>"
29758 and the column Operational semantics:
29761 <blockquote><pre><del>(a < b) ? </del>distance(a,b)
29762 <del>: -distance(b,a)</del>
29763 </pre></blockquote>
29768 Change 24.4.4 [iterator.operations]/4+5 as indicated:
29771 <blockquote><pre>template<class InputIterator>
29772 typename iterator_traits<InputIterator>::difference_type
29773 distance(InputIterator first, InputIterator last);
29777 4 <i>Effects:</i> <ins>If <tt>InputIterator</tt> meets the requirements
29778 of random access iterator then returns <tt>(last - first)</tt>,
29779 otherwise</ins> <del>R</del><ins>r</ins>eturns the number of increments
29780 <del>or decrements</del> needed to get from <tt>first</tt> to
29785 5 <i>Requires:</i> <ins>If <tt>InputIterator</tt> meets the requirements
29786 of random access iterator then <tt>last</tt> shall be reachable from
29787 <tt>first</tt> or <tt>first</tt> shall be reachable from <tt>last</tt>,
29788 otherwise</ins> <tt>last</tt> shall be reachable from <tt>first</tt>.
29804 <h3><a name="941"></a>941. Ref-qualifiers for assignment operators</h3>
29805 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
29806 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-12-18 <b>Last modified:</b> 2010-10-29</p>
29807 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
29808 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
29809 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
29810 <p><b>Discussion:</b></p>
29812 The assignment and equality operators <tt>=</tt> and <tt>==</tt> are easily confused, just
29813 because of their visual similarity, and in this case a simple typo can cause
29814 a serious bug. When the left side of an <tt>operator=</tt> is an rvalue, it's
29815 highly unlikely that the assignment was intended by the programmer:
29817 <blockquote><pre>if ( func() = value ) // Typical typo: == intended!
29818 </pre></blockquote>
29820 Built-in types don't support assignment to an rvalue, but unfortunately,
29821 a lot of types provided by the Standard Library do.
29824 Fortunately the language now offers a syntax to prevent a certain member
29825 function from having an rvalue as <tt>*this</tt>: by adding a ref-qualifier (<tt>&</tt>)
29826 to the member function declaration. Assignment operators are explicitly
29827 mentioned as a use case of ref-qualifiers, in "Extending Move Semantics
29828 To <tt>*this</tt> (Revision 1)",
29829 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm">N1821</a> by Daveed
29830 Vandevoorde and Bronek Kozicki
29833 Hereby I would like to propose adding ref-qualifiers to all appropriate
29834 assignment operators in the library.
29843 We recommend this be deferred until after the next Committee Draft.
29853 The LWG declined to move forward with
29854 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>.
29862 <p><b>Proposed resolution:</b></p>
29864 A proposed resolution is provided by the paper on this subject,
29865 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>,
29866 <i>Ref-qualifiers for assignment operators of the Standard Library</i>
29874 <h3><a name="942"></a>942. Atomics synopsis typo</h3>
29875 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
29876 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2010-10-29</p>
29877 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
29878 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
29879 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
29880 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a></p>
29881 <p><b>Discussion:</b></p>
29886 I'm looking at 29 [atomics] and can't really make sense of a couple of things.
29889 Firstly, there appears to be a typo in the <tt><cstdatomic></tt> synopsis:
29894 The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt>
29895 is missing the second parameter:
29898 <blockquote><pre>void* atomic_exchange(volatile atomic_address*);
29899 </pre></blockquote>
29905 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
29906 </pre></blockquote>
29909 Note, that this is <em>not</em> covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a> "Missing atomic exchange parameter",
29910 which only talks about the <tt>atomic_bool</tt>.
29916 <p><b>Proposed resolution:</b></p>
29918 Change the synopsis in 29 [atomics]/2:
29921 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
29922 </pre></blockquote>
29930 <h3><a name="944"></a>944. <tt>atomic<bool></tt> derive from <tt>atomic_bool</tt>?</h3>
29931 <p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
29932 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2010-10-29</p>
29933 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
29934 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
29935 <p><b>Discussion:</b></p>
29937 I think it's fairly obvious that <tt>atomic<bool></tt> is supposed to be derived
29938 from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic<integral></tt> interface),
29939 though I think the current wording doesn't support this. I raised this
29940 point along with <tt>atomic<floating-point></tt> privately with Herb and I seem
29941 to recall it came up in the resulting discussion on this list. However,
29942 I don't see anything on the current libs issue list mentioning this
29947 29.5 [atomics.types.generic]/3 reads
29951 There are full specializations over the integral types on the atomic
29952 class template. For each integral type integral in the second column of
29953 table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
29954 publicly derived from the corresponding atomic integral type in the
29955 first column of the table. These specializations shall have trivial
29956 default constructors and trivial destructors.
29960 Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
29961 so that this should probably be mentioned explicitly in the quoted paragraph.
29970 Move to open. Lawrence will draft a proposed resolution. Also, ask
29971 Howard to fix the title.
29975 Post Summit Anthony provided proposed wording.
29980 2009-10 Santa Cruz:
29985 NAD Editorial. Solved by
29986 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
29991 <p><b>Proposed resolution:</b></p>
29993 Replace paragraph 3 in 29.5 [atomics.types.generic] with
29997 -3- There are full specializations over the integral types on the <tt>atomic</tt>
29998 class template. For each integral type <tt>integral</tt> in the second column of
29999 table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
30000 publicly derived from the corresponding atomic integral type in the first
30001 column of the table.
30002 <ins>In addition, the specialization <tt>atomic<bool></tt>
30003 shall be publicly derived from <tt>atomic_bool</tt>.</ins>
30004 These specializations shall have trivial default
30005 constructors and trivial destructors.
30013 <h3><a name="945"></a>945. <tt>system_clock::rep</tt> not specified</h3>
30014 <p><b>Section:</b> 20.11.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30015 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2010-10-29</p>
30016 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
30017 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30018 <p><b>Discussion:</b></p>
30020 In 20.11.5.1 [time.clock.system], the declaration of <tt>system_clock::rep</tt> says "see
30021 below", but there is nothing below that describes it.
30031 This note refers to:
30035 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> shall be <tt>true</tt>.
30039 I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed".
30040 Perhaps an editorial note along the lines of:
30044 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
30045 shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
30059 We agree with the direction of the proposed resolution.
30060 Move to NAD Editorial.
30065 <p><b>Proposed resolution:</b></p>
30067 Add a note to 20.11.5.1 [time.clock.system], p2:
30070 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
30071 shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
30079 <h3><a name="946"></a>946. <tt>duration_cast</tt> improperly specified</h3>
30080 <p><b>Section:</b> 20.11.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30081 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2010-10-29</p>
30082 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
30083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30084 <p><b>Discussion:</b></p>
30085 20.11.3.7 [time.duration.cast]/3:
30088 .... All intermediate computations shall be
30089 carried out in the widest possible representation... .
30094 floating-point types for the moment, all this arithmetic has to be done
30095 using the implementation's largest integral type, even if both arguments
30096 use int for their representation. This seems excessive. And it's not at
30097 all clear what this means if we don't ignore floating-point types.
30101 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>.
30111 The intent of this remark is that intermediate computations are carried out
30115 <blockquote><pre>common_type<typename ToDuration::rep, Rep, intmax_t>::type
30116 </pre></blockquote>
30119 The Remark was intended to be clarifying prose supporting the rather algorithmic description
30120 of the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph
30121 3 (Remarks) would be better dropped?
30131 We view this as a specific case of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>,
30132 and should be resolved when that issue is resolved.
30141 <p><b>Proposed resolution:</b></p>
30150 <h3><a name="952"></a>952. Various threading bugs #2</h3>
30151 <p><b>Section:</b> 20.11.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30152 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30153 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
30154 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30155 <p><b>Discussion:</b></p>
30157 20.11.3.7 [time.duration.cast] specifies an implementation and imposes
30158 requirements in text (and the implementation doesn't satisfy all of the
30159 text requirements). Pick one.
30163 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>.
30167 2009-05-10 Howard adds:
30173 The <i>Remarks</i> paragraph is an English re-statement of the preceeding
30174 <i>Returns</i> clause. It was meant to be clarifying and motivating, not
30175 confusing. I'm not aware with how the <i>Remarks</i> contradicts the <i>Returns</i> clause
30176 but I'm ok with simply removing the <i>Remarks</i>.
30186 Pete suggests that this could be resolved
30187 by rephrasing the Remarks to Notes.
30190 Move to NAD Editorial.
30195 <p><b>Proposed resolution:</b></p>
30204 <h3><a name="955"></a>955. Various threading bugs #5</h3>
30205 <p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30206 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30207 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
30208 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30209 <p><b>Discussion:</b></p>
30211 20.11.1 [time.clock.req] requires that a clock type have a member
30212 typedef named <tt>time_point</tt> that names an instantiation of the
30213 template <tt>time_point</tt>, and a member named <tt>duration</tt> that
30214 names an instantiation of the template <tt>duration</tt>. This mixing of
30215 levels is confusing. The typedef names should be different from the
30220 Post Summit, Anthony provided proposed wording.
30225 2009-05-04 Howard adds:
30231 The reason that the typedef names were given the same name as the class templates
30232 was so that clients would not have to stop and think about whether they were
30233 using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
30234 template directly. In this case, one person's confusion is another person's
30235 encapsulation. The detail that sometimes one is referring to the clock's
30236 native types, and sometimes one is referring to an independent type is
30237 <em>purposefully</em> "hidden" because it is supposed to be an unimportant
30238 detail. It can be confusing to have to remember when to type <tt>duration</tt>
30239 and when to type <tt>duration_type</tt>, and there is no need to require the
30240 client to remember something like that.
30244 For example, here is code that I once wrote in testing out the usability of
30248 <blockquote><pre>template <class Clock, class Duration>
30249 void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
30251 typename Clock::<b>time_point now</b> = Clock::now();
30254 typedef typename std::common_type
30257 typename std::chrono::system_clock::<b>duration</b>
30259 typedef std::chrono::<b>duration</b><double, std::nano> ID;
30262 ID us = duration_cast<ID>(d);
30268 </pre></blockquote>
30271 I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
30272 of those declarations. It seems overly burdensome on the author of <tt>do_until</tt>:
30275 <blockquote><pre>template <class Clock, class Duration>
30276 void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
30278 typename Clock::<b>time_point<font color="#C80000">_type</font></b> now = Clock::now();
30281 typedef typename std::common_type
30284 typename std::chrono::system_clock::<b>duration<font color="#C80000">_type</font></b>
30286 typedef std::chrono::<b>duration</b><double, std::nano> ID;
30289 ID us = duration_cast<ID>(d);
30295 </pre></blockquote>
30298 Additionally I'm fairly certain that this suggestion hasn't been implemented.
30299 If it had, it would have been discovered that it is incomplete. <tt>time_point</tt>
30300 also has a nested type (purposefully) named <tt>duration</tt>.
30303 That is, the current proposed wording would put the WP into an inconsistent state.
30307 the current WP has been implemented and I've received very favorable feedback
30308 from people using this interface in real-world code.
30319 Bill agrees that distinct names should be used for distinct kinds of entities.
30322 Walter would prefer not to suffix type names,
30323 especially for such well-understood terms as "duration".
30326 Howard reminds us that the proposed resolution is incomplete, per his comment
30335 2009-06-07 Howard adds:
30341 Not meaning to be argumentative, but we have a decade of positive experience
30342 with the precedent of using the same name for the nested type as an external
30343 class representing an identical concept.
30346 <blockquote><pre>template<class Category, class T, class Distance = ptrdiff_t,
30347 class Pointer = T*, class Reference = T&>
30348 struct <b>iterator</b>
30353 template <BidirectionalIterator Iter>
30354 class <b>reverse_iterator</b>
30359 template <ValueType T, Allocator Alloc = allocator<T> >
30360 requires NothrowDestructible<T>
30364 typedef <i>implementation-defined</i> <b>iterator</b>;
30366 typedef reverse_iterator<iterator> <b>reverse_iterator</b>;
30369 </pre></blockquote>
30372 I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
30373 and <tt>reverse_iterator</tt> as nested types of the containers despite these
30374 names also having related meaning at namespace std scope.
30378 Would we really be doing programmers a favor by renaming these nested types?
30381 <blockquote><pre>template <ValueType T, Allocator Alloc = allocator<T> >
30382 requires NothrowDestructible<T>
30386 typedef <i>implementation-defined</i> <b>iterator_type</b>;
30388 typedef reverse_iterator<iterator> <b>reverse_iterator_type</b>;
30391 </pre></blockquote>
30394 I submit that such design contributes to needless verbosity which ends up
30395 reducing readability.
30400 2009-10 Santa Cruz:
30405 Mark as NAD. No concensus for changing the WP.
30410 <p><b>Proposed resolution:</b></p>
30412 Change 20.11 [time]:
30415 <blockquote><pre>...
30416 template <class Clock, class Duration = typename Clock::duration<ins>_type</ins>> class time_point;
30418 </pre></blockquote>
30421 Change 20.11.1 [time.clock.req]:
30426 <caption>Table 45 -- Clock requirements</caption>
30428 <th>Expression</th>
30429 <th>Return type</th>
30430 <th>Operational semantics</th>
30438 <td><tt>C1::duration<ins>_type</ins></tt></td>
30439 <td><tt>chrono::duration<C1::rep, C1::period></tt></td>
30440 <td>The native <tt>duration</tt> type of the clock.</td>
30443 <td><tt>C1::time_point<ins>_type</ins></tt></td>
30444 <td><tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration<ins>_type</ins><</tt></td>
30445 <td>The native <tt>time_point</tt> type of the clock. Different clocks may share a <tt>time_point<ins>_type</ins></tt>
30446 definition if it is valid to
30447 compare their <tt>time_point<ins>_type</ins></tt>s by
30448 comparing their respective
30449 <tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall
30450 refer to the same epoch.</td>
30458 <td><tt>C1::now()</tt></td>
30459 <td><tt>C1::time_point<ins>_type</ins></tt></td>
30460 <td>Returns a <tt>time_point<ins>_type</ins></tt> object
30461 representing the current point
30469 Change 20.11.5.1 [time.clock.system]:
30474 -1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
30477 <blockquote><pre>class system_clock {
30479 typedef <i>see below</i> rep;
30480 typedef ratio<<i>unspecified</i>, <i>unspecified</i>> period;
30481 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
30482 typedef chrono::time_point<system_clock> time_point<ins>_type</ins>;
30483 static const bool is_monotonic = <i>unspecified</i> ;
30485 static time_point<ins>_type</ins> now();
30488 static time_t to_time_t (const time_point<ins>_type</ins>& t);
30489 static time_point<ins>_type</ins> from_time_t(time_t t);
30491 </pre></blockquote>
30494 -2- <tt>system_clock::duration<ins>_type</ins>::min() < system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
30497 <pre>time_t to_time_t(const time_point<ins>_type</ins>& t);
30501 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
30502 point in time as <tt>t</tt> when both values are truncated to the
30503 coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
30506 <pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
30510 -4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
30511 in time as <tt>t</tt> when both values are truncated to the coarser of the
30512 precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
30517 Change X [time.clock.monotonic]:
30520 <blockquote><pre>class monotonic_clock {
30522 typedef <i>unspecified</i> rep;
30523 typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
30524 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
30525 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
30526 static const bool is_monotonic = true;
30528 static time_point<ins>_type</ins> now();
30530 </pre></blockquote>
30533 Change 20.11.5.3 [time.clock.hires]:
30536 <blockquote><pre>class high_resolution_clock {
30538 typedef <i>unspecified</i> rep;
30539 typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
30540 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
30541 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
30542 static const bool is_monotonic = true;
30544 static time_point<ins>_type</ins> now();
30546 </pre></blockquote>
30554 <h3><a name="958"></a>958. Various threading bugs #8</h3>
30555 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30556 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30557 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
30558 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30559 <p><b>Discussion:</b></p>
30561 30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
30562 with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
30563 and a returns clause that sets out in words how to determine the return
30564 value. Is this description of the return value subtly different from the
30565 description of the value returned by <tt>wait_until</tt>? Or should the effects
30566 clause and the returns clause be merged?
30575 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> and any other monotonic-clock
30580 2009-08-01 Howard adds:
30585 I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (currently Ready) addresses this issue, and
30586 that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (assuming
30591 2009-10 Santa Cruz:
30596 Mark as NAD Editorial, solved by resolution of Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>.
30601 <p><b>Proposed resolution:</b></p>
30610 <h3><a name="959"></a>959. Various threading bugs #9</h3>
30611 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30612 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30613 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
30614 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30615 <p><b>Discussion:</b></p>
30617 30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
30618 is required to compute the absolute time by adding the duration value to
30619 <tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
30629 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> and any other monotonic-clock
30634 2009-08-01 Howard adds:
30639 I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (currently Ready) addresses this issue, and
30640 that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (assuming
30645 2009-10 Santa Cruz:
30650 Leave open, but expect to be fixed by N2969 revision that Detlef is writing.
30654 2009-11-18 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
30655 Rationale added below.
30661 <p><b>Proposed resolution:</b></p>
30666 <p><b>Rationale:</b></p>
30668 <tt>condition_variable::wait_for</tt> no longer refers to
30669 <tt>monotonic_clock</tt>, so this issue is moot.
30677 <h3><a name="961"></a>961. Various threading bugs #11</h3>
30678 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
30679 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30680 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
30681 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
30682 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a></p>
30683 <p><b>Discussion:</b></p>
30685 30.4.1 [thread.mutex.requirements] describes required member
30686 functions of mutex types, and requires that they throw exceptions under
30687 certain circumstances. This is overspecified. User-defined types can
30688 abort on such errors without affecting the operation of templates
30689 supplied by standard-library.
30697 Move to open. Related to conceptualization and should probably be
30698 tackled as part of that.
30702 2009-10 Santa Cruz:
30708 Would be OK to leave it as is for time constraints, could loosen later.
30712 Mark as NAD Future.
30718 <p><b>Proposed resolution:</b></p>
30727 <h3><a name="969"></a>969. What happened to Library Issue 475?</h3>
30728 <p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30729 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-01-12 <b>Last modified:</b> 2010-10-29</p>
30730 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
30731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30732 <p><b>Discussion:</b></p>
30734 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a> has CD1 status, but the non-normative note in
30735 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
30737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>
30738 (25.2.4 [alg.foreach] in both drafts).
30746 Move to NAD Editorial.
30750 <p><b>Proposed resolution:</b></p>
30752 Restore the non-normative note. It might need to be expressed in terms of concepts.
30760 <h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
30761 <p><b>Section:</b> 19.5.2.5 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30762 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19 <b>Last modified:</b> 2010-10-29</p>
30763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30764 <p><b>Discussion:</b></p>
30766 Anthony Williams raised the question in c++std-lib-22987 "why is there
30767 <tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
30770 The function <tt>make_error_code(errc e)</tt> is not required, since
30771 <tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
30772 conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
30773 initial confusion over the distinction between POSIX and operating
30774 systems that conform to the POSIX spec.
30791 The designer of the facility (Christopher Kohlhoff)
30792 strongly disagrees that there is an issue here,
30793 and especially disagrees with the proposed resolution.
30794 Bill would prefer to be conservative and not apply this proposed resolution.
30795 Move to Open, and recommend strong consideration for NAD status.
30799 2009-05-21 Beman adds:
30804 My mistake. Christopher and Bill are correct and the issue should be
30805 NAD. The function is needed by users.
30809 2009-07-21 Christopher Kohlhoff adds rationale for <tt>make_error_code</tt>:
30815 Users (and indeed library implementers) may need to use the
30816 <tt>errc</tt> codes in portable code. For example:
30819 <blockquote><pre>void do_foo(error_code& ec)
30821 #if defined(_WIN32)
30822 // Windows implementation ...
30823 #elif defined(linux)
30824 // Linux implementation ...
30826 // do_foo not supported on this platform
30827 ec = make_error_code(errc::not_supported);
30830 </pre></blockquote>
30844 <p><b>Proposed resolution:</b></p>
30846 Change System error support 19.5 [syserr], Header <tt><system_error></tt>
30847 synopsis, as indicated:
30850 <blockquote><pre><del>error_code make_error_code(errc e);</del>
30851 error_condition make_error_condition(errc e);
30852 </pre></blockquote>
30855 Delete from Class error_code non-member functions
30856 19.5.2.5 [syserr.errcode.nonmembers]:
30859 <blockquote><pre><del>error_code make_error_code(errc e);</del>
30862 <del><i>Returns:</i> <tt>error_code(static_cast<int>(e),
30863 generic_category)</tt>.</del>
30873 <h3><a name="972"></a>972. The term "Assignable" undefined but still in use</h3>
30874 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30875 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
30876 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
30877 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
30878 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30879 <p><b>Discussion:</b></p>
30881 Previous versions of the Draft had a table, defining the Assignable
30882 requirement. For example
30883 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>
30884 Table 79, "Assignable requirements". But I guess the term "Assignable"
30885 is outdated by now, because the current Committee Draft provides
30886 <tt>MoveAssignable</tt>, <tt>CopyAssignable</tt>, and <tt>TriviallyCopyAssignable</tt> concepts
30887 instead. And as far as I can see, it no longer has a definition of
30888 <tt>Assignable</tt>. (Please correct me if I'm wrong.) Still the word
30889 "Assignable" is used in eight places in the Draft,
30890 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
30894 Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"?
30902 Move to NAD Editorial.
30906 <p><b>Proposed resolution:</b></p>
30909 Change Exception Propagation 18.8.5 [propagation]:
30912 <tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>,
30913 <tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>.
30917 Change Class template reference_wrapper 20.8.4 [refwrap]:
30920 <tt>reference_wrapper<T></tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>.
30923 Change Placeholders 20.8.10.1.3 [func.bind.place]:
30926 It is implementation defined whether placeholder types are <tt><ins>Copy</ins>Assignable</tt>. <tt><ins>Copy</ins>Assignable</tt> placeholders' copy assignment operators shall not throw exceptions.
30929 Change Class template shared_ptr 20.9.10.2 [util.smartptr.shared]:
30932 Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
30935 Change Class template weak_ptr 20.9.10.3 [util.smartptr.weak]:
30938 Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
30941 Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
30944 <i>Requires:</i> <tt>state_type</tt> shall meet the requirements of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>, <tt>CopyConstructible</tt> (20.1.8), and <tt>DefaultConstructible</tt> types.
30947 Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
30950 In addition to the requirements set forth below, instances of
30951 <tt>seed_seq</tt> shall meet the requirements of <tt>CopyConstructible</tt> (20.1.8) and of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>.
30955 Note: The proposed resolution of this issue does not deal with the
30956 instance of the term "Assignable" in D.12.1 [auto.ptr], as this is dealt
30957 with more specifically by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, "<tt>auto_ptr</tt> characteristics", submitted
30958 by Maarten Hilferink.
30967 <h3><a name="973"></a>973. auto_ptr characteristics</h3>
30968 <p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
30969 <b>Submitter:</b> Maarten Hilferink <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2010-10-29</p>
30970 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
30971 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
30972 <p><b>Discussion:</b></p>
30974 I think that the Note of D.12.1 [auto.ptr], paragraph 3 needs a rewrite
30975 since "Assignable" is no longer defined as a concept.
30976 The relationship of <tt>auto_ptr</tt> with the new <tt>CopyAssignable</tt>, <tt>MoveAssignable</tt>,
30977 and <tt>MoveConstructible</tt> concepts should be clarified.
30978 Furthermore, since the use of <tt>auto_ptr</tt> is depreciated anyway,
30979 we can also omit a description of its intended use.
30987 We agree with the intent of the proposed resolution.
30988 Move to NAD Editorial.
30992 <p><b>Proposed resolution:</b></p>
30994 Change D.12.1 [auto.ptr], paragraph 3:
30998 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
30999 <tt>auto_ptr</tt> owns the ob ject it holds a pointer to. Copying an
31000 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
31001 destination. If more than one <tt>auto_ptr</tt> owns the same ob ject at
31002 the same time the behavior of the program is undefined. [<i>Note:</i>
31003 The uses of <tt>auto_ptr</tt> include providing temporary
31004 exception-safety for dynamically allocated memory, passing ownership of
31005 dynamically allocated memory to a function, and returning dynamically
31006 allocated memory from a function.
31007 <del><tt>auto_ptr</tt> does not meet the
31008 <tt>CopyConstructible</tt> and <tt>Assignable</tt> requirements for
31009 standard library container elements and thus instantiating a standard
31010 library container with an <tt>auto_ptr</tt> results in undefined
31013 <ins>Instances of <tt>auto_ptr</tt> shall
31014 meet the <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>
31015 requirements, but do not meet the <tt>CopyConstructible</tt> and
31016 <tt>CopyAssignable</tt> requirements.</ins>
31017 -- <i>end note</i>]
31025 <h3><a name="976"></a>976. Class template std::stack should be movable</h3>
31026 <p><b>Section:</b> 23.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
31027 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01 <b>Last modified:</b> 2010-10-29</p>
31028 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
31029 <p><b>Discussion:</b></p>
31031 The synopsis given in 23.5.3.1 [stack.defn] does not show up
31034 <blockquote><pre>requires MoveConstructible<Cont> stack(stack&&);
31035 requires MoveAssignable<Cont> stack& operator=(stack&&);
31036 </pre></blockquote>
31039 although the other container adaptors do provide corresponding
31049 We agree with the proposed resolution.
31052 Move to Tentatively Ready.
31062 Moved from Tentatively Ready to Open only because the wording needs to be
31063 tweaked for concepts removal.
31067 2009-08-18 Daniel updates the wording and Howard sets to Review.
31072 2009-08-23 Howard adds:
31077 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a> also adds these move members using an editorially different
31082 2009-10 Santa Cruz:
31087 Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>.
31092 <p><b>Proposed resolution:</b></p>
31094 In the class stack synopsis of 23.5.3.1 [stack.defn] insert:
31097 <blockquote><pre>template <class T, class Container = deque<T> >
31100 explicit stack(const Container&);
31101 explicit stack(Container&& = Container());
31102 <ins>stack(stack&& s) : c(std::move(s.c)) {}</ins>
31103 <ins>stack& operator=(stack&& s) { c = std::move(s.c); return *this; }</ins>
31106 </pre></blockquote>
31116 <h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
31117 <p><b>Section:</b> 24.5.2 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31118 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2010-10-29</p>
31119 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
31120 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31121 <p><b>Discussion:</b></p>
31123 The new concepts for the insert iterators mandate an extra copy when
31124 inserting an lvalue:
31127 <blockquote><pre>requires CopyConstructible<Cont::value_type>
31128 back_insert_iterator<Cont>&
31129 operator=(const Cont::value_type& value);
31132 -1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
31137 The reason is to convert <tt>value</tt> into an rvalue because the current
31138 <tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
31142 <blockquote><pre>concept BackInsertionContainer<typename C> : Container<C> {
31143 void push_back(C&, value_type&&);
31145 </pre></blockquote>
31148 Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
31149 fails to concept check.
31153 A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
31154 the client can pass in the parameter type for <tt>push_back</tt> similar to
31155 what is already done for the <tt>OutputIterator</tt> concept:
31158 <blockquote><pre>concept BackInsertionContainer<typename C, typename Value = C::value_type&&>
31159 : Container<C> {
31160 void push_back(C&, Value);
31162 </pre></blockquote>
31165 This allows the assignment operator to be adjusted appropriately:
31168 <blockquote><pre>requires BackInsertionContainer<Cont, Cont::value_type const&> &&
31169 CopyConstructible<Cont::value_type>
31170 back_insert_iterator<Cont>&
31171 operator=(const Cont::value_type& value);
31174 -1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
31179 We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
31184 Solution and wording collaborated on by Doug and Howard.
31194 Howard notes that "these operations behaved efficiently until concepts were added."
31197 Alisdair is uncertain that the proposed resolution is syntactically correct.
31200 Move to Open, and recommend the issue be deferred until after the next
31201 Committee Draft is issued.
31206 2009-10 Santa Cruz:
31211 NAD, solved by the removal of concepts.
31216 <p><b>Proposed resolution:</b></p>
31218 Change [container.concepts.free]:
31222 <pre>concept FrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31223 : Container<C> {
31224 void push_front(C&, <del>value_type&&</del> <ins>Value</ins>);
31226 axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
31227 x == (push_front(c, x), front(c));
31234 <pre>concept BackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31235 : Container<C> {
31236 void push_back(C&, <del>value_type&&</del> <ins>Value</ins>);
31242 <pre>concept InsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31243 : Container<C> {
31244 iterator insert(C&, const_iterator, <del>value_type&&</del> <ins>Value</ins>);
31246 axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
31247 v == *insert(c, position, v);
31255 Change [container.concepts.member]:
31259 <pre>auto concept MemberFrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31260 : MemberContainer<C> {
31261 void C::push_front(<del>value_type&&</del> <ins>Value</ins>);
31263 axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
31264 x == (c.push_front(x), c.front());
31271 <pre>auto concept MemberBackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31272 : MemberContainer<C> {
31273 void C::push_back(<del>value_type&&</del> <ins>Value</ins>);
31279 <pre>auto concept MemberInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
31280 : MemberContainer<C> {
31281 iterator C::insert(const_iterator, <del>value_type&&</del> <ins>Value</ins>);
31283 axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
31284 v == *c.insert(position, v);
31291 Change [container.concepts.maps]:
31295 <pre>template <MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
31296 concept_map FrontInsertionContainer<C<ins>, Value</ins>> {
31297 typedef Container<C>::value_type value_type;
31299 void push_front(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_front(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
31305 <pre>template <MemberBackInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
31306 concept_map BackInsertionContainer<C<ins>, Value</ins>> {
31307 typedef Container<C>::value_type value_type;
31309 void push_back(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_back(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
31315 <pre>template <MemberInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
31316 concept_map InsertionContainer<C<ins>, Value</ins>> {
31317 typedef Container<C>::value_type value_type;
31318 Container<C>::iterator insert(C& c, Container<C>::const_iterator i, <del>value_type&&</del> <ins>Value</ins> v)
31319 { return c.insert(i, static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
31326 Change 24.5.2.1 [back.insert.iterator]:
31329 <blockquote><pre>template <BackInsertionContainer Cont>
31330 class back_insert_iterator {
31332 requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
31333 <del>CopyConstructible<Cont::value_type></del>
31334 back_insert_iterator<Cont>&
31335 operator=(const Cont::value_type& value);
31337 </pre></blockquote>
31340 Change 24.5.2.2.2 [back.insert.iter.op=]:
31344 <pre>requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
31345 <del>CopyConstructible<Cont::value_type></del>
31346 back_insert_iterator<Cont>&
31347 operator=(const Cont::value_type& value);
31350 -1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
31355 Change 24.5.2.3 [front.insert.iterator]:
31358 <blockquote><pre>template <FrontInsertionContainer Cont>
31359 class front_insert_iterator {
31361 requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
31362 <del>CopyConstructible<Cont::value_type></del>
31363 front_insert_iterator<Cont>&
31364 operator=(const Cont::value_type& value);
31366 </pre></blockquote>
31369 Change 24.5.2.4.2 [front.insert.iter.op=]:
31373 <pre>requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
31374 <del>CopyConstructible<Cont::value_type></del>
31375 front_insert_iterator<Cont>&
31376 operator=(const Cont::value_type& value);
31379 -1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
31384 Change 24.5.2.5 [insert.iterator]:
31387 <blockquote><pre>template <InsertionContainer Cont>
31388 class insert_iterator {
31390 requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
31391 <del>CopyConstructible<Cont::value_type></del>
31392 insert_iterator<Cont>&
31393 operator=(const Cont::value_type& value);
31395 </pre></blockquote>
31398 Change 24.5.2.6.2 [insert.iter.op=]:
31402 <pre>requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
31403 <del>CopyConstructible<Cont::value_type></del>
31404 insert_iterator<Cont>&
31405 operator=(const Cont::value_type& value);
31409 -1- <i>Effects:</i>
31411 <blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>);
31413 </pre></blockquote>
31423 <h3><a name="979"></a>979. Bad example</h3>
31424 <p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
31425 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-03 <b>Last modified:</b> 2010-10-29</p>
31426 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
31427 <p><b>Discussion:</b></p>
31429 24.5.3 [move.iterators] has an incorrect example:
31434 -2- [<i>Example:</i>
31437 <blockquote><pre>set<string> s;
31438 // populate the set s
31439 vector<string> v1(s.begin(), s.end()); // copies strings into v1
31440 vector<string> v2(make_move_iterator(s.begin()),
31441 make_move_iterator(s.end())); // moves strings into v2
31442 </pre></blockquote>
31445 <i>-- end example</i>]
31450 One can not move from a <tt>set</tt> because the iterators return <tt>const</tt>
31459 We agree with the proposed resolution. Move to NAD Editorial.
31464 <p><b>Proposed resolution:</b></p>
31466 Change 24.5.3 [move.iterators]/2:
31471 -2- [<i>Example:</i>
31474 <blockquote><pre><del>set</del><ins>list</ins><string> s;
31475 // populate the <del>set</del><ins>list</ins> s
31476 vector<string> v1(s.begin(), s.end()); // copies strings into v1
31477 vector<string> v2(make_move_iterator(s.begin()),
31478 make_move_iterator(s.end())); // moves strings into v2
31479 </pre></blockquote>
31482 <i>-- end example</i>]
31491 <h3><a name="980"></a>980. <tt>mutex lock()</tt> missing error conditions</h3>
31492 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31493 <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2009-02-07 <b>Last modified:</b> 2010-10-29</p>
31494 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
31495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31496 <p><b>Discussion:</b></p>
31498 POSIX 2008 adds two return values for <tt>pthread_mutex_xxxlock()</tt>:
31499 <tt>EOWNERDEAD</tt> (<tt>owner_dead</tt>) and <tt>ENOTRECOVERABLE</tt>
31500 (<tt>state_not_recoverable</tt>). In the first case the mutex is locked,
31501 in the second case the mutex is not locked.
31505 Throwing an exception in the first case can be incompatible with the use
31506 of Locks, since the <tt>Lock::owns_lock()</tt> will be <tt>false</tt> when the lock is
31514 <blockquote><pre>//Suppose mutex.lock() throws "owner_dead"
31515 unique_lock ul(&mutex);
31516 //mutex left locked if "owner_dead" is thrown
31517 </pre></blockquote>
31520 Throwing an exception with <tt>owner_dead</tt> might be also undesirable if
31521 robust-mutex support is added to C++ and the user has the equivalent of
31522 <tt>pthread_mutex_consistent()</tt> to notify the user has fixed the corrupted
31523 data and the mutex state should be marked consistent.
31528 For <tt>state_not_recoverable</tt> add it to the list of Error conditions:
31531 For <tt>owner_dead</tt>, no proposed resolution.
31541 Not a defect. Handling these error conditions is an implementation
31542 detail and must be handled below the C++ interface.
31547 <p><b>Proposed resolution:</b></p>
31550 Add to 30.4.1 [thread.mutex.requirements], p12:
31555 -12- <i>Error conditions:</i>
31560 <tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change
31561 the state of the mutex.
31564 <tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able
31568 <tt>device_or_resource_busy</tt> -- if the mutex is already locked and blocking is not possible.
31571 <ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins>
31581 <h3><a name="988"></a>988. <tt>Reflexivity</tt> meaningless?</h3>
31582 <p><b>Section:</b> X [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31583 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2010-10-29</p>
31584 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
31585 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31586 <p><b>Discussion:</b></p>
31588 X [concept.comparison] p2:
31591 Due to the subtle meaning of <tt>==</tt> inside axioms, the <tt>Reflexivity</tt> axiom does
31592 not do anything as written. It merely states that a value is substitutable
31593 with itself, rather than asserting a property of the <tt>==</tt> operator.
31597 Original proposed resolution:
31601 Change the definition of <tt>Reflexivity</tt> in X [concept.comparison]:
31604 <blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; }
31605 </pre></blockquote>
31614 Alisdair: I was wrong.
31623 <p><b>Proposed resolution:</b></p>
31633 <h3><a name="989"></a>989. late_check and library</h3>
31634 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
31635 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2010-10-29</p>
31636 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
31637 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
31638 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
31639 <p><b>Discussion:</b></p>
31641 The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup
31642 inside a constrained context, and so inhibit concept map adaption by users
31643 to meet template requirements.
31646 Do we need some text in clause 17 prohibitting use of late_check in library
31647 template definitions unless otherwise documented?
31656 We need something like this, but it should be a more general statement
31657 about implementations respecting the concept maps provided by the
31658 user. Use of late_check is one way in which implementations can
31659 subvert the concept maps provided by the user, but there are other
31660 ways as well ("pattern-based" overloading, tricks with "auto" concept
31661 maps and defaulted associated type arguments).
31669 Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
31673 <p><b>Proposed resolution:</b></p>
31680 <h3><a name="992"></a>992. Response to UK 169</h3>
31681 <p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31682 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
31683 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
31684 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31685 <p><b>Discussion:</b></p>
31686 <p><b>Addresses UK 169</b></p>
31688 This phrasing contradicts later freedom to implement the C standard
31689 library portions in the global namespace as well as std. (17.6.2.3p4)
31697 The proposed wording seems to go too far.
31708 Howard to add NB reference to the description of this issue.
31711 Move to NAD. This comment is informative and not normative by the use of
31712 the word "are" instead of the word "shall."
31715 A note linking to Annex D would help clarify the intention, here.
31718 Robert to Open a separate issue proposing that the standard C headers be
31719 undeprecated, for the purpose of clarifying the standard.
31724 2009-07-22 Bill modified the proposed wording with a clarifying footnote.
31730 <p><b>Proposed resolution:</b></p>
31732 Add a footnote to 17.6.1.1 [contents], p2:
31737 -2- All library entities except macros, <tt>operator new</tt> and <tt>operator
31738 delete</tt> are defined within the namespace <tt>std</tt> or namespaces
31739 nested within namespace <tt>std</tt><ins><sup>*</sup></ins>.
31743 <sup>*</sup>The C standard library headers D.7 [depr.c.headers] also define
31744 names within the global namespace, while the C++ headers for
31745 C library facilities 17.6.1.2 [headers] may also define names within
31746 the global namespace.
31756 <h3><a name="995"></a>995. Operational Semantics Unclear</h3>
31757 <p><b>Section:</b> 17.5.1.3 [structure.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31758 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2010-10-29</p>
31759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31760 <p><b>Discussion:</b></p>
31762 As a practical matter there's disagreement on the meaning of <i>operational
31763 semantics</i>. If the text in 17.5.1.3 [structure.requirements]p4 isn't
31764 clear, it should be clarified. However, it's not clear whether the
31765 disagreement is merely due to people not being aware of the text.
31773 Agree with the recommended NAD resolution.
31777 <p><b>Proposed resolution:</b></p>
31779 Recommend NAD. The text in 17.5.1.3 [structure.requirements] is
31788 <h3><a name="996"></a>996. Move operation not well specified</h3>
31789 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
31790 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2010-10-29</p>
31791 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
31792 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
31793 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31794 <p><b>Discussion:</b></p>
31796 There are lots of places in the standard where we talk about "the move
31797 constructor" but where we mean "the move operation," i.e. <tt>T( move( x ) )</tt>.
31800 We also don't account for whether that operation modifies <tt>x</tt> or not, and
31809 Move to Open, pending proposed wording from Dave for further
31821 Move to NAD. We define what we expect from a moved-from object in Table 34 [movesconstructible].
31826 <p><b>Proposed resolution:</b></p>
31835 <h3><a name="1000"></a>1000. adjacent_find is over-constrained</h3>
31836 <p><b>Section:</b> 25.2.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
31837 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2010-10-23</p>
31838 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
31839 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
31840 <p><b>Discussion:</b></p>
31842 <b>Addresses UK 296</b>
31846 <tt>adjacent_find</tt> in C++03 allows an arbitrary predicate, but in C++0x
31847 <tt>EqualityComparable/EquivalenceRelation</tt> is required. This forbids a
31848 number of use cases, including:
31854 <tt>adjacent_find(begin, end, less<double>)</tt>
31858 place where a range is not ordered in decreasing order - in use to check
31864 <tt>adjacent_find(begin, end, DistanceBiggerThan(6) ) )</tt>
31868 place in a range where values differ by more than a given value - in use
31869 to check an algorithm which produces points in space does not generate
31870 points too far apart.
31877 A number of books use predicate which are not equivalence relations in
31878 examples, including "Thinking in C++" and "C++ Primer".
31882 Adding the requirement that the predicate is an <tt>EquivalenceRelation</tt>
31883 does not appear to open up any possibility for a more optimised algorithm.
31888 <p><b>Proposed resolution:</b></p>
31890 Change the definition of adjacent_find in the synopsis of 25 [algorithms]
31891 and 25.2.8 [alg.adjacent.find] to:
31894 <blockquote><pre>template<ForwardIterator Iter>
31895 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><Iter::value_type<ins>, Iter::value_type</ins>>
31896 Iter adjacent_find(Iter first, Iter last);
31898 template<ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins><auto, Iter::value_type<ins>, Iter::value_type</ins>> Pred>
31899 requires CopyConstructible<Pred>
31900 Iter adjacent_find(Iter first, Iter last, Pred pred);
31901 </pre></blockquote>
31908 <h3><a name="1001"></a>1001. Pointers, concepts and headers</h3>
31909 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
31910 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10 <b>Last modified:</b> 2010-10-23</p>
31911 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
31912 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
31913 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
31914 <p><b>Discussion:</b></p>
31916 <p><b>Addresses UK 78</b></p>
31919 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>.
31923 This is effectively an extension of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>.
31926 We know there is an increasing trend (encouraged by conformance testers and
31927 some users) that each library header should supply no more than required to
31928 satisfy the synopsis in the standard. This is typically achieved by
31929 breaking larger headers into smaller subsets, and judicious use of forward
31933 If we apply this policy to C++0x (per
31934 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>)
31935 it will be very surprising for
31936 people using library algorithms over ranges defined by pointers that they
31937 must <tt>#include <iterator_concepts></tt> for their code to compile again. That is
31938 because pointers do not satisfy any of the iterator concepts without the
31939 <tt>concept_map</tt> supplied in this header.
31942 Therefore, I suggest we should require all library headers that make use of
31943 iterator concepts are specifically required to <tt>#include <iterator_concepts></tt>.
31946 At a minimum, the list of headers would be: (assuming all are constrained by
31949 <blockquote><pre>algorithm
31958 memory // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a> is adopted
31970 </pre></blockquote>
31979 The same problems exists for <tt><memory_concepts></tt> and
31980 <tt><container_concepts></tt>.
31983 In order to compile <tt><vector></tt> you just need the
31984 definitions of the concepts in <tt><memory_concepts></tt>, the
31985 concept maps defined there are not necessary. Yet, from the user point
31986 of view, if the concept map template for <tt>AllocatableElement</tt> are
31987 not in scope, <tt><vector></tt> is pretty useless. Same for
31988 <tt><tuple></tt> and <tt>ConstructibleWithAllocator</tt>.
31991 Similarly, <tt><queue></tt> is not very useful if the concept map
31992 template for <tt>QueueLikeContainer</tt> is not in scope, although the
31993 definition of concept alone is theoretically sufficient.
31996 There's a pattern here: if a concept has concept maps "attached", they
31997 should never be separated.
32002 Beman provided the proposed resolution for the May 2009 mailing. He
32009 <p>Initially I tried to specify exactly what header should include what other
32010 headers. This was verbose, error prone, hard to maintain, and appeared to add
32011 little value compared to just stating the general rule.</p>
32021 Pete believes the proposed wording overconstrains implementers.
32022 Instead of specifying the mechanism,
32023 he prefers a solution that spells out what needs to be declared,
32024 rather than how those declarations are to be provided,
32028 A C++ header shall provide the names
32029 that are required to be defined in that header.
32032 Bill suggests approaching the wording from a programmer's perspective.
32033 We may want to consider promising that certain widely-used headers
32034 (e.g., the concept headers) are included when needed by other headers.
32035 He feels, however, there is nothing broken now,
32036 although we may want to consider "something nicer."
32039 Move to Open status.
32045 2009-06-16 Beman updated the proposed resolution:
32051 <li>The mechanism is no longer specified, as requested in Batavia.</li>
32052 <li>The footnote has been removed since it specified mechanism and also did
32053 not reflect existing practice.</li>
32054 <li>A sentence was added that makes it clear that the existing practice is
32060 2009-07-15 Beman updated the proposed resolution:
32065 2009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt:
32071 <li>Strike two pieces of text considered unnecessary.</li>
32072 <li>Change "definitions" to "declarations and definitions" in two places.</li>
32073 <li>Wording tightened slightly.</li>
32084 Revised Proposed Resolution:
32087 A C++ header may include other C++ headers. A C++ header shall provide
32088 the declarations and definitions that appear in its synopsis (3.2
32089 [basic.def.odr]). A C++ header shown in its synopsis as including other
32090 C++ headers shall provide the declarations and definitions that appear
32091 in the synopses of those other headers.
32094 Alisdair: Does this address the BSI comment?
32097 Beman: There were several overlapping comments. I tried to handle them
32098 all with one resolution.
32101 Alisdair: I'd prefer to see this closed as NAD and have this resolution
32102 be the subject of some other, new issue.
32105 Move to NAD Concepts. Howard to open a new issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>) in Ready state with the
32106 Proposed Resolution above. Beman will write up a discussion for the new
32113 <p><b>Proposed resolution:</b></p>
32114 <p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
32119 A C++ header may include other C++
32120 headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
32121 the declarations and definitions that appear in its synopsis
32122 (3.2 [basic.def.odr]). A C++ header shown in its synopsis as including
32123 other C++ headers shall provide the same declarations and definitions as
32124 if those other headers were included.</ins>
32127 <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains
32128 any needed definition (3.2).</del></p>
32137 <h3><a name="1002"></a>1002. Response to UK 170</h3>
32138 <p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
32139 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32140 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
32141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32142 <p><b>Discussion:</b></p>
32144 <p><b>Addresses UK 170</b></p>
32147 One of goals of C++0x is to make language easier to teach and for
32148 'incidental' programmers. The fine-grained headers of the C++ library
32149 are valuable in large scale systems for managing dependencies and
32150 optimising build times, but overcomplicated for simple development and
32151 tutorials. Add additional headers to support the whole library through a
32152 single include statement.
32160 We do not all agree that this is an issue,
32161 but we agree that if it needs solving this is the right way to do it.
32162 Move to Tentatively Ready.
32166 2009-07-06 Beman notes:
32173 adds a header <tt><std></tt>.
32176 There is a paper to be looked at,
32177 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>
32178 Aggregation headers, that adds
32179 a header <tt><std-all></tt> that is the same thing except it excludes
32180 deprecated headers.
32181 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>
32182 also proposes a second aggregation header.
32185 Seems like this issue should be held in abeyance until the LWG has had
32186 a chance to look at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>.
32191 2009-07-06 Howard: I've pulled this issue back to Review.
32201 No consensus for change.
32206 <p><b>Proposed resolution:</b></p>
32208 Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
32211 An additional header <tt><std></tt> shall have the effect of
32212 supplying the entire standard library. [<i>Note:</i> for example, it
32213 might be implemented as a file with an <tt>#include</tt> statement for each of the
32214 headers listed in tables 13 and 14. <i>-- end note</i>]
32222 <h3><a name="1003"></a>1003. Response to JP 23</h3>
32223 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
32224 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32225 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
32226 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32227 <p><b>Discussion:</b></p>
32229 <p><b>Addresses JP 23</b></p>
32232 There is a freestanding implementation including
32233 <tt><type_traits></tt>, <tt><array></tt>,
32234 <tt><ratio></tt>, lately added to Table 13, C++ library headers.
32235 Programmers think them useful and hope that these headers are also added
32236 to Table 15, C++ headers for freestanding implementations, that shows
32237 the set of headers which a freestanding implementation shall include at
32241 <p><b>Original proposed resolution</b></p>
32244 Add <tt><type_traits></tt>, <tt><array></tt>,
32245 <tt><ratio></tt> to Table 15.
32255 The <tt><array></tt> header has far too many dependencies to require for a
32256 free-standing implementation.
32259 The <tt><ratio></tt> header would be useful, has no dependencies, but is not
32260 strictly necessary.
32263 The <tt><type_traits></tt> header is fundamentally a core language facility with a
32264 library interface, so should be supported.
32268 (it is anticipated the resolution will come via an update to paper
32269 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>)
32270 (see also LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>)
32279 Leave in Review status pending a paper on freestanding implementations
32293 We considered all of the listed headers, and found a compelling case
32294 only for the inclusion of <tt><type_traits></tt> in the list of headers required
32295 of a freestanding implementation.
32298 See Martin Tasker's paper
32299 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2932.pdf">Fixing Freestanding</a>
32300 which provides the wording to include <tt><type_traits></tt> into freestanding
32307 <p><b>Proposed resolution:</b></p>
32309 Add <tt><type_traits></tt> to Table 15.
32318 <h3><a name="1005"></a>1005. <tt>numeric_limits</tt> partial specializations not concept enabled</h3>
32319 <p><b>Section:</b> 18.3.1.1 [numeric.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32320 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32321 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32322 <p><b>Discussion:</b></p>
32324 <p><b>Addresses JP 26</b></p>
32327 <tt>numeric_limits</tt> [partial specializations] does not use concept.
32336 Alisdair will provide a soltion as part of treatment of axioms and LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>.
32345 Alisdair recommends NAD as the partial specializations are already
32346 constrained by requirements on the primary template.
32354 The Working Draft does not in general repeat a primary template's constraints
32355 in any specializations.
32360 2009-05-25 Howard adds:
32365 A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the
32366 correct resolution of this issue. Indeed the discussion also casts doubt that
32367 the current proposed wording is the correct resolution as well. Personally I'm
32368 inclined to reset the status to Open. However I'm reverting the status to
32369 that which it had prior to the Batavia recommendation. I'm setting back to Review.
32373 <p><b>Proposed resolution:</b></p>
32375 Change 18.3.1.1 [numeric.limits]:
32378 <blockquote><pre>template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const T>;
32379 template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<volatile T>;
32380 template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const volatile T>;
32381 </pre></blockquote>
32389 <h3><a name="1007"></a>1007. <tt>throw_with_nested</tt> not concept enabled</h3>
32390 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32391 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32392 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
32393 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32394 <p><b>Discussion:</b></p>
32396 <p><b>Addresses JP 29</b></p>
32399 <tt>throw_with_nested</tt> does not use concept.
32413 <p><b>Proposed resolution:</b></p>
32416 Alisdair initially proposed wording in
32417 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
32420 We are awaiting an updated paper based on feedback from the San Francisco
32429 <h3><a name="1008"></a>1008. <tt>nested_exception</tt> wording unclear</h3>
32430 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
32431 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32432 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
32433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32434 <p><b>Discussion:</b></p>
32436 <p><b>Addresses JP 31</b></p>
32439 It is difficult to understand in which case <tt>nested_exception</tt> is applied.
32448 Alisdair will add an example in an update to
32449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
32453 2009-10 Santa Cruz:
32458 It doesn't appear that N2619 really addresses this. Alisdair to propose wording.
32467 Mark issue 1008 as NAD, the type is adequately described.
32472 <p><b>Rationale:</b></p>
32474 nested_exception is intended to be inherited from by exception classes
32475 that are to be thrown during the handling of another exception, i.e.
32476 when translating from one exception type to another. nested_exception
32477 allows the originally thrown exception to be easily retained in that
32482 <p><b>Proposed resolution:</b></p>
32489 <h3><a name="1009"></a>1009. <tt>InputIterator</tt> post-increment dangerous</h3>
32490 <p><b>Section:</b> 24.2.2 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
32491 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32492 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32493 <p><b>Discussion:</b></p>
32495 <p><b>Addresses UK 251</b></p>
32498 The post-increment operator is dangerous for a general InputIterator.
32499 The multi-pass guarantees that make it meaningful are defined as part of
32500 the ForwardIterator refinement. Any change will affect only constrained
32501 templates that have not yet been written, so should not break existing
32502 user iterators which remain free to add these operations. This change
32503 will also affect the generalised OutputIterator, although there is no
32504 percieved need for the post-increment operator in this case either.
32508 2009-07-28 Alisdair adds:
32513 We still think the issue is relevant, but needs totally rewording in
32514 non-concept language. We would like to see the issue retained as Open,
32515 rather than deferred as NAD Concepts. Review status is no longer
32520 2009-10 Santa Cruz:
32525 NAD. Without concepts we do not feel that input iterator post increment
32531 <p><b>Proposed resolution:</b></p>
32533 Change 24.2.2 [iterator.iterators]:
32536 <blockquote><pre>concept Iterator<typename X> : Semiregular<X> {
32537 MoveConstructible reference = typename X::reference;
32538 <del>MoveConstructible postincrement_result;</del>
32540 <del>requires HasDereference<postincrement_result>;</del>
32542 reference operator*(X&&);
32543 X& operator++(X&);
32544 <del>postincrement_result operator++(X&, int);</del>
32549 <pre><del>postincrement_result operator++(X& r, int);</del>
32553 <del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
32559 Change 24.2.3 [input.iterators]:
32563 <pre>concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> {
32564 ObjectType value_type = typename X::value_type;
32565 MoveConstructible pointer = typename X::pointer;
32567 SignedIntegralLike difference_type = typename X::difference_type;
32569 requires IntegralType<difference_type>
32570 && Convertible<reference, const value_type &>;
32571 && Convertible<pointer, const value_type*>;
32573 <del>requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</del>
32575 pointer operator->(const X&);
32581 Change 24.2.4 [output.iterators]:
32585 <pre>auto concept OutputIterator<typename X, typename Value> {
32586 requires Iterator<X>;
32588 typename reference = Iterator<X>::reference;
32589 <del>typename postincrement_result = Iterator<X>::postincrement_result;</del>
32590 requires SameType<reference, Iterator<X>::reference>
32591 <del>&& SameType<postincrement_result, Iterator<X>::postincrement_result></del>
32592 <del>&& Convertible<postincrement_result, const X&></del>
32593 && HasAssign<reference, Value>
32594 <del>&& HasAssign<HasDereference<postincrement_result>::result_type, Value></del>;
32600 Change 24.2.5 [forward.iterators]:
32604 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a> which is attempting to change this same area in a compatible
32610 <pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
32611 <del>requires Convertible<postincrement_result, const X&>;</del>
32613 <ins>MoveConstructible postincrement_result;</ins>
32614 <ins>requires HasDereference<postincrement_result>
32615 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</ins>
32617 <ins>postincrement_result operator++(X&, int);</ins>
32619 axiom MultiPass(X a, X b) {
32620 if (a == b) *a == *b;
32621 if (a == b) ++a == ++b;
32630 <pre><ins>postincrement_result operator++(X& r, int);</ins>
32635 <ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
32647 <h3><a name="1010"></a>1010. <tt>operator-=</tt> should use default in concept</h3>
32648 <p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32649 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32650 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
32651 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32652 <p><b>Discussion:</b></p>
32654 <p><b>Addresses UK 263</b></p>
32657 This requirement on <tt>operator-=</tt> would be better expressed as a default
32658 implementation in the concept, with a matching axiom.
32666 The proposed resolution should also remove
32667 paragraph 5 and the declaration that precedes it.
32668 Further, we should provide an axiom
32669 that captures the desired semantics.
32670 This may be a broader policy to be applied.
32675 <p><b>Proposed resolution:</b></p>
32677 Change 24.2.7 [random.access.iterators]:
32680 <blockquote><pre>concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> {
32682 X& operator-=(X& <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins>
32685 </pre></blockquote>
32693 <h3><a name="1013"></a>1013. Response to UK 305</h3>
32694 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
32695 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32696 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
32697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
32698 <p><b>Discussion:</b></p>
32700 <p><b>Addresses UK 305</b></p>
32703 The negative requirement on <tt>IsSameType</tt> is a hold-over from an earlier
32704 draught with a variadic template form of <tt>min/max</tt> algorith. It is no
32713 We agree with the proposed resolution.
32714 Move to Tentatively Ready.
32723 We believe this is NAD, but this needs to be reviewed against the
32724 post-remove-concepts draft.
32729 <p><b>Proposed resolution:</b></p>
32731 Change 25 [algorithms]:
32734 <blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
32735 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32736 const T& min(const T& a, const T& b, Compare comp);
32738 template<class T, StrictWeakOrder<auto, T> Compare>
32739 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32740 const T& max(const T& a, const T& b, Compare comp);
32742 template<class T, StrictWeakOrder<auto, T> Compare>
32743 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32744 pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
32745 </pre></blockquote>
32748 Change 25.4.7 [alg.min.max], p1, p9 and p17:
32751 <blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
32752 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32753 const T& min(const T& a, const T& b, Compare comp);
32755 template<class T, StrictWeakOrder<auto, T> Compare>
32756 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32757 const T& max(const T& a, const T& b, Compare comp);
32759 template<class T, StrictWeakOrder<auto, T> Compare>
32760 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
32761 pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
32762 </pre></blockquote>
32770 <h3><a name="1015"></a>1015. Response to UK 199</h3>
32771 <p><b>Section:</b> X [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32772 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32773 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
32774 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32775 <p><b>Discussion:</b></p>
32777 <p><b>Addresses UK 199</b></p>
32780 The requirement that programs do not supply <tt>concept_maps</tt> should
32781 probably be users do not supply their own <tt>concept_map</tt>
32782 specializations. The program will almost certainly supply
32783 <tt>concept_maps</tt> - the standard itself supplies a specialization
32784 for <tt>RvalueOf</tt> references. Note that the term <i>program</i> is
32785 defined in 3.5 [basic.link]p1 and makes no account of the
32786 standard library being treated differently to user written code.
32790 2009-05-09 Alisdair adds:
32796 The same problem is present in the words added for the
32797 <tt>LvalueReference/RvalueReference</tt> concepts last meeting.
32800 With three subsections requiring the same constraint, I'm wondering if there
32801 is a better way to organise this section.
32802 Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in
32803 [concept.support]? While they can be implemented purely as a
32804 library feature without additional compiler support, they are pretty
32805 fundamental and we want the same restriction on user-concept maps as is
32815 We agree with the issue,
32816 but believe the wording needs further improvement.
32817 We want to investigate current definitions for nomenclature such as
32818 "user" and "program."
32819 Move to Open pending the recommended investigation.
32823 <p><b>Proposed resolution:</b></p>
32825 Change X [concept.transform] p2:
32829 -2- A <del>program</del> <ins>user</ins> shall not provide concept maps for
32830 any concept in 20.1.1.
32834 Change [concept.true] p2:
32838 -2- <i>Requires:</i> a <del>program</del> <ins>user</ins> shall not
32839 provide a concept map for the <tt>True</tt> concept.
32843 Change [concept.classify] p2:
32847 -2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept
32848 maps for any concept in this section.
32857 <h3><a name="1016"></a>1016. Response to JP 33</h3>
32858 <p><b>Section:</b> X [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32859 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32860 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
32861 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32862 <p><b>Discussion:</b></p>
32864 <p><b>Addresses JP 33</b></p>
32867 <tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN.
32870 <p><b>Original proposed resolution:</b></p>
32873 Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>.
32877 Post Summit, Alisdair adds:
32883 I don't understand the proposed resolution - there is no such thing as a
32884 'negative' concept_map, and these concepts are auto concepts that match
32885 float/double etc. Also not clear how we are supposed to match values to
32889 Recommend NAD and treat as a subset of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>.
32895 <p><b>Proposed resolution:</b></p>
32905 <h3><a name="1017"></a>1017. Response to US 66</h3>
32906 <p><b>Section:</b> X [concept.regular] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32907 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32908 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32909 <p><b>Discussion:</b></p>
32911 <p><b>Addresses US 66</b></p>
32914 Application of the <tt>Regular</tt> concept to floating-point types appears to be
32915 controversial (see long discussion on std-lib reflector).
32918 <p><b>Original proposed resolution:</b></p>
32921 State that the <tt>Regular</tt> concept does not apply to floating-point types.
32931 Recommend that we handle the same as JP 33 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>.
32936 Post Summit, Alisdair adds:
32942 Recommend Open, and review after resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a> and revised axiom
32949 <p><b>Proposed resolution:</b></p>
32956 <h3><a name="1018"></a>1018. Response to US 70</h3>
32957 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
32958 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
32959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
32960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
32961 <p><b>Discussion:</b></p>
32963 <p><b>Addresses US 70</b></p>
32966 Specifications now expressed via narrative text are more accurately and
32967 clearly expressed via executable code.
32970 Wherever concepts are available that directly match this section's type
32971 traits, express the traits in terms of the concepts instead of via
32972 narrative text. Where the type traits do not quite match the
32973 corresponding concepts, bring the two into alignment so as to avoid two
32974 nearly-identical notions.
32984 We think that this is a good idea, but it requires a lot of work. If someone
32985 submits a paper proposing specific changes, we would be happy to review it
32986 at the next meeting.
32992 <p><b>Proposed resolution:</b></p>
32999 <h3><a name="1020"></a>1020. Response to UK 204</h3>
33000 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
33001 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33002 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
33003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
33004 <p><b>Discussion:</b></p>
33006 <p><b>Addresses UK 204</b></p>
33009 It is not possible to create a variant union based on a parameter pack
33010 expansion, e.g. to implement a classic discriminated union template.
33013 <p><b>Original proposed resolutuion:</b></p>
33016 Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>.
33025 Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
33029 Post Summit, Alisdair adds:
33035 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
33036 proposes an extension to the <tt>[[align]]</tt> attribute
33037 that further diminishes the need for this template. Recommend NAD.
33041 2009-10 Santa Cruz:
33046 Mark NAD as suggested.
33051 <p><b>Proposed resolution:</b></p>
33058 <h3><a name="1022"></a>1022. Response to UK 212</h3>
33059 <p><b>Section:</b> 20.9.11 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
33060 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33061 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
33062 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
33063 <p><b>Discussion:</b></p>
33065 <p><b>Addresses UK 212</b></p>
33068 The pointer-safety API is nothing to do with smart pointers, so does not
33069 belong in 20.9.10 [util.smartptr]. In fact it is a set of language
33070 support features are really belongs in clause 18 [language.support], with the contents declared in a header that
33071 deals with language-support of memory management.
33080 Agree in principle, but not with the proposed resolution. We believe it
33081 belongs either a subsection of either 20 [utilities] or 20.9 [memory] as part of the general reorganization of 20 [utilities]. The declaration should stay in
33082 <tt><memory></tt>.
33087 <p><b>Proposed resolution:</b></p>
33094 <h3><a name="1023"></a>1023. Response to DE 22</h3>
33095 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
33096 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33097 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
33098 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
33099 <p><b>Discussion:</b></p>
33101 <p><b>Addresses DE 22</b></p>
33103 <p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</p>
33106 The conditions for deriving from <tt>std::unary_function</tt> and
33107 <tt>std::binary_function</tt> are unclear: The condition would also be satisfied if
33108 <tt>ArgTypes</tt> were <tt>std::vector<T1></tt>, because it (arguably)
33109 "contains" <tt>T1</tt>.
33118 Agree. <tt>std::reference_wrapper</tt> has the same structure, and we
33119 suggest that <tt>std::function</tt> be presented in the same way as
33120 <tt>std::reference_wrapper</tt>.
33124 2009-05-09 Alisdair adds:
33129 Phrasing should be "publicly and
33130 unambiguously derived from" and probably back in reference_wrapper too. Updated
33139 We agree with the proposed wording.
33140 Move to NAD Editorial.
33144 <p><b>Proposed resolution:</b></p>
33146 (no changes to <tt><functional></tt> synopsis required)
33150 Change synopsis in Class template function 20.8.14.2 [func.wrap.func]:
33153 <blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
33154 class function<R(ArgTypes...)>
33155 : public unary_function<T1, R> // <del><i>iff</i> sizeof...(ArgTypes) == 1 <i>and</i></del> <ins><i>see below</i></ins>
33156 <del>// ArgTypes <i>contains</i> T1</del>
33157 : public binary_function<T1, T2, R> // <del><i>iff</i> sizeof...(ArgTypes) == 2 <i>and</i></del> <ins><i>see below</i></ins>
33158 <del>// ArgTypes <i>contains</i> T1 <i>and</i> T2</del>
33161 </pre></blockquote>
33164 Add new p1/p2 before 20.8.14.2.1 [func.wrap.func.con]:
33169 The template instantiation <tt>function<R(T1)></tt> shall be publicly and
33170 unambiguously derived from
33171 <tt>std::unary_function<T1,R></tt> if and only if the template type parameter
33172 is a function type taking one argument of type <tt>T1</tt> and returning <tt>R</tt>.
33176 The template instantiation <tt>function<R(T1,T2)></tt> shall be publicly and
33177 unambiguously derived from
33178 <tt>std::binary_function<T1,T2,R></tt> if and only if the template type
33179 parameter is a function type taking two arguments of type <tt>T1</tt> and <tt>T2</tt> and
33180 returning <tt>R</tt>.
33183 <pre>explicit function();
33193 <h3><a name="1024"></a>1024. Response to JP 39</h3>
33194 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33195 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33196 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
33197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33198 <p><b>Discussion:</b></p>
33200 <p><b>Addresses JP 39</b></p>
33203 There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>.
33207 2009-05-01 Daniel adds:
33212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a> removes the second constructor.
33220 We agree with the proposed resolution.
33221 Move to Tentatively Ready.
33222 If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a> is accepted,
33223 the changes to the second constructor
33224 in this issue are moot.
33233 Constructors have no definition.
33238 <p><b>Proposed resolution:</b></p>
33240 Correct as follows in 20.8.14.2 [func.wrap.func] (class definition)
33243 <blockquote><pre> template<class F, Allocator Alloc>
33244 <ins>requires ConstructibleWithAllocator<F, Alloc>
33245 && call=Callable<F, ArgTypes...>
33246 && Convertible<call::result_type, R></ins>
33247 function(allocator_arg_t, const Alloc&, F);
33248 template<class F, Allocator Alloc>
33249 <ins>requires ConstructibleWithAllocator<F,Alloc>
33250 && call=Callable<F, ArgTypes...>
33251 && Convertible<call::result_type, R></ins>
33252 function(allocator_arg_t, const Alloc&, F&&);
33253 </pre></blockquote>
33261 <h3><a name="1025"></a>1025. Response to UK 208</h3>
33262 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
33263 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33264 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
33265 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
33266 <p><b>Discussion:</b></p>
33268 <p><b>Addresses UK 208</b></p>
33271 <tt>std::hash</tt> should be implemented for much more of the standard
33272 library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the
33273 standard containers.
33278 <p><b>Proposed resolution:</b></p>
33285 <h3><a name="1026"></a>1026. Response to UK 209</h3>
33286 <p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33287 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33288 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
33289 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33290 <p><b>Discussion:</b></p>
33292 <p><b>Addresses UK 209</b></p>
33295 Smart pointers cannot be used in constrained templates.
33304 We look forward to a paper on this topic. We recommend no action until a
33305 paper is available. We understand that a paper is forthcoming.
33314 <tt>shared_ptr<T></tt> and <tt>weak_ptr<T></tt> support all
33315 types <tt>T</tt> for which <tt>T*</tt> is valid. In other words, a
33316 possible (partial) resolution is to change class <tt>T</tt> to
33317 <tt>PointeeType T</tt> for <tt>shared_ptr</tt>, <tt>weak_ptr</tt> and
33318 possibly <tt>enable_shared_from_this</tt>.
33323 <p><b>Proposed resolution:</b></p>
33330 <h3><a name="1027"></a>1027. Response to UK 213</h3>
33331 <p><b>Section:</b> 20.9.5 [default.allocator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33332 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33333 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33334 <p><b>Discussion:</b></p>
33336 <p><b>Addresses UK 213</b></p>
33339 <tt>std::allocator</tt> should be constrained to simplify its use on constrained
33340 contexts. This library component models allocation from free store via the
33341 new operator so choose constraints to
33342 match. The Allocator concept allows for a wider variety of allocators that
33343 users may choose to supply if their allocation model does not require
33344 operator new, without impacting the
33345 requirements of this template.
33349 Suggested direction:
33352 The primary allocator template should be constrained to require
33353 <tt>ObjectType<T></tt> and <tt>FreeStoreAllocatable<T></tt>.
33354 Further operations to be constrained as required.
33363 Agree as stated. A future paper will address additional related issues.
33368 <p><b>Proposed resolution:</b></p>
33375 <h3><a name="1028"></a>1028. Response to UK 214</h3>
33376 <p><b>Section:</b> 20.9.6 [storage.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33377 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33378 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33379 <p><b>Discussion:</b></p>
33381 <p><b>Addresses UK 214</b></p>
33384 <tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely
33385 used in constrained templates
33394 We look forward to a paper on this topic. We recommend no action until a
33395 paper is available.
33399 Post Summit Alisdair provided wording and rationale.
33405 <p><b>Proposed resolution:</b></p>
33410 Update the synopsis for <tt><memory></tt>
33412 <blockquote><pre>// 20.7.8, raw storage iterator:
33413 template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
33414 <ins>requires OutputIterator< OutIter, T ></ins>
33415 class raw_storage_iterator;
33417 <ins>template <ForwardIterator OutIter, ObjectType T>
33418 requires OutputIterator< OutIter, T >
33419 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
33420 </pre></blockquote>
33424 20.9.6 [storage.iterator] p1
33427 Replace class template definition with:
33429 <blockquote><pre>namespace std {
33430 template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
33431 <ins>requires OutputIterator< OutIter, T ></ins>
33432 class raw_storage_iterator
33433 : public iterator<output_iterator_tag,void,void,void,void> {
33435 explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x);
33437 raw_storage_iterator<del><OutputIterator,T></del>& operator*();
33438 raw_storage_iterator<del><OutputIterator,T></del>& operator=(const T& element);
33439 raw_storage_iterator<del><OutputIterator,T></del>& operator++();
33440 raw_storage_iterator<del><OutputIterator,T></del> operator++(int);
33443 <ins>template <ForwardIterator OutIter, ObjectType T>
33444 requires OutputIterator< OutIter, T >
33445 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
33447 </pre></blockquote>
33450 <p><b>Rationale:</b></p>
33452 <tt>raw_storage_iterator</tt> has to adapt a <tt>ForwardIterator</tt>,
33453 rather than just an <tt>InputIterator</tt> for two reasons:
33458 The initial iterator passed by value is expected to remain valid,
33459 pointing to the initialized region of memory.
33462 to avoid breaking the declaration of post-increment operator which would
33463 require some kind of proxy formulation to support generalised InputIterators.
33473 <h3><a name="1029"></a>1029. Response to UK 210</h3>
33474 <p><b>Section:</b> 20.9.8 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33475 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33476 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
33477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33478 <p><b>Discussion:</b></p>
33480 <p><b>Addresses UK 210</b></p>
33482 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a></p>
33485 Specialized algorithms for memory managenment need requirements to be
33486 easily usable in constrained templates.
33495 We look forward to a paper on this topic. We recommend no action until a
33496 paper is available.
33500 Post Summit Alisdair provided wording.
33517 I suggest <tt>Size</tt> should require <tt>IntegralLike</tt> and not <tt>UnsignedIntegralLike</tt>,
33518 because otherwise simple int-literals could not be provided as arguments
33519 and it would conflict with other algorithms that only require <tt>IntegralLike</tt>.
33523 The current for-loop-test relies on evaluation in boolean context which is
33524 not provided by <tt>ArithmeticLike</tt> and it's refinements. I propose to change the
33525 corresponding for-loop-headers to:
33529 for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n > Size(0); ++result, ++first, --n) {</tt>
33532 for <tt>uninitialized_fill_n</tt>: <tt>for (; n > Size(0); ++first, --n) {</tt>
33543 For the record I agree with Daniel's suggestion.
33550 <p><b>Proposed resolution:</b></p>
33555 Update the synopsis for <tt><memory></tt>
33557 <blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
33558 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
33559 <ins>requires ForwardIterator<OutIter></ins>
33560 <del>ForwardIterator</del> <ins>OutIter</ins>
33561 uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
33562 <del>ForwardIterator</del> <ins>OutIter</ins> result);
33564 template <<del>class</del> InputIterator <ins>InIter</ins>,
33565 <del>class</del> <ins>IntegralLike</ins> Size,
33566 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
33567 <ins>requires ForwardIterator<OutIter></ins>
33568 <del>ForwardIterator</del> <ins>OutIter</ins>
33569 uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
33570 <del>ForwardIterator</del> <ins>OutIter</ins> result);
33572 template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
33573 <ins>requires Constructible< Iter::value_type, const T& ></ins>
33574 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
33577 template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
33578 <ins>requires Constructible< Iter::value_type, const T& ></ins>
33580 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
33581 </pre></blockquote>
33588 uninitialized_copy 20.9.8.2 [uninitialized.copy]
33591 <blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
33592 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
33593 <ins>requires ForwardIterator<OutIter></ins>
33594 <del>ForwardIterator</del> <ins>OutIter</ins>
33595 uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
33596 <del>ForwardIterator</del> <ins>OutIter</ins> result);
33601 -1- <i>Effects:</i>
33603 <blockquote><pre>for (; first != last; ++result, ++first) {
33604 new (static_cast<void*>(&*result))
33605 <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
33607 </pre></blockquote>
33610 -2- <i>Returns:</i> <tt>result</tt>
33615 <pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
33616 <del>class</del> <ins>IntegralLike</ins> Size,
33617 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
33618 <ins>requires ForwardIterator<OutIter></ins>
33619 <del>ForwardIterator</del> <ins>OutIter</ins>
33620 uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
33621 <del>ForwardIterator</del> <ins>OutIter</ins> result);
33628 <blockquote><pre>for ( ; n > <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) {
33629 new (static_cast<void*>(&*result))
33630 <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
33632 </pre></blockquote>
33634 -4- <i>Returns:</i> result
33642 uninitialized_fill 20.9.8.3 [uninitialized.fill]
33645 <blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
33646 <ins>requires Constructible< Iter::value_type, const T& ></ins>
33647 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
33653 -1- <i>Effects:</i>
33655 <blockquote><pre>for (; first != last; ++first) {
33656 new ( static_cast<void*>( &*first) )
33657 <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
33659 </pre></blockquote>
33665 uninitialized_fill_n 20.9.8.4 [uninitialized.fill.n]
33668 <blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
33669 <ins>requires Constructible< Iter::value_type, const T& ></ins>
33671 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
33676 -1- <i>Effects:</i>
33678 <blockquote><pre>for (; n<del>--</del> <ins>> Size(0)</ins>; ++first<ins>, --n</ins>) {
33679 new ( static_cast<void*>( &*first) )
33680 <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
33682 </pre></blockquote>
33692 <h3><a name="1031"></a>1031. Response to US 78</h3>
33693 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
33694 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33695 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
33696 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
33697 <p><b>Discussion:</b></p>
33699 <p><b>Addresses US 78</b></p>
33702 There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
33703 <tt>unique_ptr</tt>. Add an interface that performs the conversion.
33712 We look forward to a paper on this topic. We recommend no action until a
33713 paper is available. We believe that the shared pointer must use the default
33714 deleter for the conversion to succeed.
33723 This is basically a request for <tt>shared_ptr<>::release</tt> in
33724 disguise, with all the associated problems. Not a good idea.
33728 2009-07 post-Frankfurt:
33734 The rationale for the omission of a release() member function from shared_ptr is given in:
33735 <a href="http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm">http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm</a>
33738 The implementation of such a member is non-trivial (and maybe
33739 impossible), because it would need to account for the deleter.
33744 2009-07-26 Howard sets to Tentatively NAD Future.
33750 I took an online poll and got 3 votes for NAD and 3 for NAD Future. Personally
33751 I prefer NAD Future as this does refer to an extension that could conceivably be
33752 considered beyond C++0X.
33756 However such an extension would need to solve a couple of problems:
33760 <li>What is the interface for such a conversion when the <tt>shared_ptr</tt> does
33761 not have unique ownership? Throw an exception? Create a null <tt>unique_ptr</tt>?
33762 Undefined behavior?
33767 How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
33770 I do not believe it is possible to implement a general answer to this question.
33771 The <tt>shared_ptr</tt> deleter is a run time (or construction time) characteristic.
33772 The <tt>unique_ptr</tt> deleter is a compile time characteristic. In general one
33773 can not know to what type of <tt>unqiue_ptr</tt> you are converting to.
33776 One answer is for the user of the conversion to specify the deleter type and perhaps
33777 throw an exception if the specification turns out to be incorrect.
33780 Another answer is for the conversion to only be valid when the underlying deleter
33781 is <tt>default_delete</tt>. We would probalby need to specify that this is indeed the
33782 underlying deleter of a <tt>shared_ptr</tt> when a custom deleter is not given in
33789 At any rate, there are non-trivial design issues which would need to be implemented
33790 and tested in the field for usability prior to standardization.
33800 Moved to NAD Future.
33805 <p><b>Proposed resolution:</b></p>
33812 <h3><a name="1032"></a>1032. Response to JP 45</h3>
33813 <p><b>Section:</b> 20.11 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33814 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
33815 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
33816 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33817 <p><b>Discussion:</b></p>
33819 <p><b>Addresses JP 45</b></p>
33822 <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>
33823 don't correspond to concept.
33825 <blockquote><pre>template <class Rep, class Period = ratio<1>> class duration;
33826 template <class Clock, class Duration = typename Clock::duration> class time_point;
33827 </pre></blockquote>
33829 Make concept for <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>.
33830 Fix 20.11 [time] and <tt>wait_until</tt>
33831 and <tt>wait_for</tt>'s template parameter at 30 [thread].
33840 We agree that this section needs concepts. We look forward to a paper on
33841 this topic. We recommend no action until a paper is available.
33846 <p><b>Proposed resolution:</b></p>
33853 <h3><a name="1035"></a>1035. Response to UK 226</h3>
33854 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
33855 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
33856 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
33857 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
33858 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
33859 <p><b>Discussion:</b></p>
33861 <p><b>Addresses UK 226</b></p>
33864 <tt><array></tt> must be added to this list. In particular it
33865 doesn't satisfy: - no <tt>swap()</tt> function invalidates any
33866 references, pointers, or iterators referring to the elements of the
33867 containers being swapped. and probably doesn't satisfy: - no
33868 <tt>swap()</tt> function throws an exception.
33871 If <tt><array></tt> remains a container, this will have to also
33872 reference <tt>array</tt>, which will then have to say which of these
33873 points it satisfies.
33882 Agree. The proposed resolution is incomplete. Further work required.
33886 2009-05-01 Daniel adds:
33891 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a> also suggests
33892 adding move constructor to this.
33896 2009-07 post-Frankfurt:
33901 Howard is to draft a note that explains what happens to references.
33905 2009-10 Santa Cruz:
33910 Mark as NAD. No consensus for change.
33916 2009-08-01 Howard provided wording.
33920 <p><b>Proposed resolution:</b></p>
33922 Add a paragraph to 23.3.1.2 [array.special]:
33925 <blockquote><pre>template <Swappable T, size_t N> void swap(array<T,N>& x, array<T,N>& y);
33931 <blockquote><pre>swap_ranges(x.begin(), x.end(), y.begin());
33932 </pre></blockquote>
33936 Outstanding iterators, references and pointers may be invalidated.
33937 \97 <i>end note</i>]
33947 <h3><a name="1036"></a>1036. Response to UK 231</h3>
33948 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
33949 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
33950 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
33951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
33952 <p><b>Discussion:</b></p>
33954 <p><b>Addresses UK 231</b></p>
33957 p9-p11 are redundant now that Concepts define what it means to be an
33958 Iterator and guide overload resolution accordingly.
33967 Agree with issue and change to 23.2.3 [sequence.reqmts]. The
33968 changes required to 21 [strings] will be part of the general
33969 concept support for that clause.
33974 <p><b>Proposed resolution:</b></p>
33976 Strike 23.2.3 [sequence.reqmts]p9-11. Make sure <tt>std::basic_string</tt>
33977 has constraints similar to
33978 <tt>std::vector</tt> to meet this old guarantee.
33986 <h3><a name="1041"></a>1041. Response to UK 239</h3>
33987 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
33988 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
33989 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
33990 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
33991 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
33992 <p><b>Discussion:</b></p>
33994 <p><b>Addresses UK 239</b></p>
33997 It is not possible to take a move-only key out of an unordered
33998 container, such as (<tt>multi</tt>)<tt>set</tt> or
33999 (<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
34003 Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
34006 <tt>a.extract(q)></tt>, Return type <tt>pair<key, iterator></tt>
34007 Extracts the element pointed to by <tt>q</tt> and erases it from the
34008 <tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
34009 <tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
34010 following <tt>q</tt> prior to the element being erased. If no such
34011 element exists,returns <tt>a.end()</tt>.
34020 We look forward to a paper on this topic. We recommend no action until a
34021 paper is available. The paper would need to address exception safety.
34025 Post Summit Alisdair adds:
34030 Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
34034 2009-07 post-Frankfurt:
34039 Leave Open. Alisdair to contact Chris Jefferson about this.
34043 2009-09-20 Howard adds:
34048 See the 2009-09-19 comment of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a> for an API which
34049 accomplishes this functionality and also addresses several other use
34050 cases which this proposal does not.
34054 2009-10 Santa Cruz:
34059 Mark as NAD Future. No consensus to make the change at this time.
34064 <p><b>Proposed resolution:</b></p>
34066 In 23.2.4 [associative.reqmts] Table 85, add:
34071 <caption>Table 85 -- Associative container requirements (in addition to container)</caption>
34073 <th>Expression</th>
34074 <th>Return type</th>
34075 <th>Assertion/note<br>pre-/post-condition</th>
34076 <th>Complexity</th>
34078 <tr><td><tt>a.erase(q)</tt></td>
34083 <td><ins><tt>a.extract(q)</tt></ins></td>
34084 <td><ins><tt>pair<key_type, iterator></tt></ins></td>
34085 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
34086 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
34087 pointing to the element immediately following <tt>q</tt> prior to the element being
34088 erased. If no such element
34089 exists, returns <tt>a.end()</tt>.</ins></td>
34090 <td><ins>amortized constant</ins></td>
34096 In 23.2.5 [unord.req] Table 87, add:
34101 <caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
34103 <th>Expression</th>
34104 <th>Return type</th>
34105 <th>Assertion/note<br>pre-/post-condition</th>
34106 <th>Complexity</th>
34108 <tr><td><tt>a.erase(q)</tt></td>
34113 <td><ins><tt>a.extract(q)</tt></ins></td>
34114 <td><ins><tt>pair<key_type, iterator></tt></ins></td>
34115 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
34116 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
34117 pointing to the element immediately following <tt>q</tt> prior to the element being
34118 erased. If no such element
34119 exists, returns <tt>a.end()</tt>.</ins></td>
34120 <td><ins>amortized constant</ins></td>
34130 <h3><a name="1042"></a>1042. Response to UK 244</h3>
34131 <p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
34132 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34133 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
34134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
34135 <p><b>Discussion:</b></p>
34137 <p><b>Addresses UK 244</b></p>
34140 The validity of the expression <tt>&a[n] == &a[0] + n</tt> is contingent on
34141 <tt>operator&</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
34142 requirements in table 30 in C++2003). However this constraint has been
34143 lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
34144 actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
34145 file a separate comment there and cross-reference).
34149 Suggested solution:
34153 Define a <tt>ContiguousStrorage</tt> and apply it to
34154 <tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
34163 Agree with the issue but not the details of the proposed solution. Walter to
34164 provide wording for the new concept.
34168 Post Summit Alisdair adds:
34173 Another LWG subgroup wondered if this concept
34174 should extend to <tt>complex<T></tt>, and so not be built on the container concept at
34179 2009-07 post-Frankfurt:
34184 Leave Open, pending a post-Concepts Working Draft.
34188 2009-10 Santa Cruz:
34193 Mark issue 1042 as NAD, in rationale state that this was solved by removal of concepts.
34198 <p><b>Proposed resolution:</b></p>
34200 Add to <tt><container_concepts></tt> synopsis in [container.concepts]
34203 <blockquote><pre><ins>concept< typename C > ContiguousStorageContainer <i>see below</i>;</ins>
34204 </pre></blockquote>
34207 Add a new section to the end of [container.concepts]
34212 23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
34215 <pre>concept ContiguousStorageContainer< typename C >
34216 : Container<C>
34218 value_type* data(C&);
34220 axiom Contiguity(C& c, size_type i) {
34221 if( i < size(c) ) {
34222 addressof( * (data(c) + i) )
34223 == addressof( * advance(data(c), i) );
34230 The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
34231 are allocated in a single region of memory, and are stored sequentially
34232 without intervening padding other than to meet alignment requirements.
34233 For example, the elements may be stored in a
34234 single array of suitable length.
34237 <pre>value_type * data( C& );
34241 <i>Returns:</i> a pointer to the first element in the region of storage.
34242 Result is unspecified for an empty container.
34248 Change 23.3.1 [array] p1:
34252 -1- The header <tt><array></tt> defines a class template for
34253 storing fixed-size sequences of objects. An <tt>array</tt> supports
34254 random access iterators. An instance of <tt>array<T, N></tt>
34255 stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
34256 N</tt> is an invariant. The elements of an <tt>array</tt> are stored
34257 contiguously, meaning that <del>if <tt>a</tt> is</del> an
34258 <tt>array<T, N></tt> <del>then it obeys the identity <tt>&a[n]
34259 == &a[0] + n</tt> for all <tt>0 <= n < N</tt></del>
34260 <ins>satisfies the concept <tt>ContiguousStorageContainer< array<T,
34261 N>></tt></ins>.
34265 Add to the synopsis in 23.3.1 [array]:
34268 <blockquote><pre> ...
34270 const T * data() const;
34273 <ins>template< typename T, size_t N ></ins>
34274 <ins>concept_map ContiguousStorageContainer< array<T, N>> {};</ins>
34276 </pre></blockquote>
34279 Change 23.4.1 [vector] p1:
34283 A <tt>vector</tt> is a sequence container that supports random access
34284 iterators. In addition, it supports (amortized) constant time insert and
34285 erase operations at the end; insert and erase in the middle take linear
34286 time. Storage management is handled automatically, though hints can be
34287 given to improve efficiency. The elements of a vector are stored
34288 contiguously, meaning that <del>if <tt>v</tt> is</del> a
34289 <tt>vector<T, Alloc></tt> <ins>(</ins>where <tt>T</tt> is some
34290 type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
34291 identity <tt>&v[n] == &v[0] + n</tt> for all <tt>0 <= n <
34292 v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer<
34293 vector< T, Alloc>></tt></ins>.
34297 Add at the end of the synopsis in 23.4.1 [vector] p2:
34300 <blockquote><pre><ins>template< typename T, typename A >
34301 requires !SameType< T, bool >
34302 concept_map ContiguousStorageContainer< vector<T, A>> {};</ins>
34303 </pre></blockquote>
34307 <p><b>Rationale:</b></p>
34308 Solved by removal of concepts.
34315 <h3><a name="1043"></a>1043. Response to US 91</h3>
34316 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34317 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34318 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
34319 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
34320 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34321 <p><b>Discussion:</b></p>
34323 <p><b>Addresses US 91</b></p>
34326 It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
34327 (as used in 1.10 [intro.multithread]).
34331 Suggested solution:
34335 Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
34339 Anthony Williams adds:
34344 In 29.6 [atomics.types.operations] p18 it says that "These
34345 operations are atomic read-modify-write operations" (final sentence).
34346 This is overly restrictive on the implementations of
34347 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
34348 native CAS instruction.
34358 Group agrees with the resolution as proposed by Anthony Williams in the attached note.
34366 We recommend the proposed resolution be reviewed
34367 by members of the Concurrency Subgroup.
34371 2009-07 post-Frankfurt:
34376 This is likely to be addressed by Lawrence's upcoming paper. He will
34377 adopt the proposed resolution.
34381 2009-08-17 Handled by
34382 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
34387 2009-10 Santa Cruz:
34392 NAD Editorial. Solved by
34393 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
34398 <p><b>Proposed resolution:</b></p>
34400 Change 29.6 [atomics.types.operations] p18:
34404 -18- <i>Effects:</i> Atomically, compares the value pointed to by
34405 <tt>object</tt> or by <tt>this</tt> for equality with that in
34406 <tt>expected</tt>, and if true, replaces the value pointed to by
34407 <tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
34408 the value in <tt>expected</tt> with the value pointed to by
34409 <tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
34410 memory is affected according to the value of <tt>success</tt>, and if the
34411 comparison is false, memory is affected according to the value of
34412 <tt>failure</tt>. When only one <tt>memory_order</tt> argument is
34413 supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
34414 of <tt>failure</tt> is <tt>order</tt> except that a value of
34415 <tt>memory_order_acq_rel</tt> shall be replaced by the value
34416 <tt>memory_order_acquire</tt> and a value of
34417 <tt>memory_order_release</tt> shall be replaced by the value
34418 <tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
34419 <del>T</del><ins>t</ins>hese operations are atomic
34420 read-modify-write operations (1.10).
34421 <ins>If the comparison is <tt>false</tt>, these
34422 operations are atomic load operations.</ins>
34431 <h3><a name="1046"></a>1046. Response to UK 329</h3>
34432 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34433 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34434 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
34435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34436 <p><b>Discussion:</b></p>
34438 <p><b>Addresses UK 329</b></p>
34441 <tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
34442 framework for creating future values, but a simple function to tie all
34443 three components together is missing. Note that we only need a *simple*
34444 facility for C++0x. Advanced thread pools are to be left for TR2.
34452 Provide a simple function along the lines of:
34454 <blockquote><pre>template< typename F, typename ... Args >
34455 requires Callable< F, Args... >
34456 future< Callable::result_type > async( F&& f, Args && ... );
34457 </pre></blockquote>
34460 Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
34461 invoking <tt>f</tt> with <tt>forward<Args>(args...)</tt>
34462 but details are left unspecified to allow different scheduling and thread
34463 spawning implementations.
34466 It is unspecified whether a task submitted to async is run on its own thread
34467 or a thread previously used for another async task. If a call to <tt>async</tt>
34468 succeeds, it shall be safe to wait for it from any thread.
34471 The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls.
34474 No two incomplete async tasks shall see the same value of
34475 <tt>this_thread::get_id()</tt>.
34478 [<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
34479 fixed-size pool with no queue. If the
34480 library is unable to spawn a new thread or there are no free worker threads
34481 then the <tt>async</tt> call should fail. <i>--end note</i>]
34491 The concurrency subgroup has revisited this issue and decided that it
34492 could be considered a defect according to the Kona compromise. A task
34493 group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
34494 paper for Frankfort proposing a simple asynchronous launch facility
34495 returning a <tt>future</tt>. It was agreed that the callable must be run on a
34496 separate thread from the caller, but not necessarily a brand-new thread.
34497 The proposal might or might not allow for an implementation that uses
34498 fixed-size or unlimited thread pools.
34501 Bjarne in c++std-lib-23121: I think that what we agreed was that to
34502 avoid deadlock <tt>async()</tt> would almost certainly be specified to launch in
34503 a different thread from the thread that executed <tt>async()</tt>, but I don't
34504 think it was a specific design constraint.
34509 2009-10 Santa Cruz:
34514 Proposed resolution: see
34515 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2996.html">N2996</a>
34516 (Herb's and Lawrence's paper on Async). Move state to NAD editorial.
34521 <p><b>Proposed resolution:</b></p>
34528 <h3><a name="1047"></a>1047. Response to UK 334</h3>
34529 <p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34530 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34531 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
34532 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34533 <p><b>Discussion:</b></p>
34535 <p><b>Addresses UK 334</b></p>
34538 Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
34539 not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
34540 call, and will wait for the future to become ready.
34550 Agree, move to Review.
34555 2009-04-03 Thomas J. Gritzan adds:
34561 This issue also applies to <tt>shared_future::get()</tt>.
34569 Add a paragraph to 30.6.7 [futures.shared_future]:
34572 <blockquote><pre>void shared_future<void>::get() const;
34575 <i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous
34576 result associated with <tt>*this</tt>.
34586 It is not clear to us that this is an issue,
34587 because the proposed resolution's Effects clause seems to duplicate
34588 information already present in the Synchronization clause.
34589 Keep in Review status.
34593 2009-10 Santa Cruz:
34598 NAD Editorial. Solved by
34599 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34604 <p><b>Proposed resolution:</b></p>
34606 Add a paragraph to 30.6.6 [futures.unique_future]:
34609 <blockquote><pre>R&& unique_future::get();
34610 R& unique_future<R&>::get();
34611 void unique_future<void>::get();
34614 <p><i>Note:</i>...</p>
34616 <ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
34617 block on the asynchronous result associated with <tt>*this</tt>.</ins>
34620 <i>Synchronization:</i> if <tt>*this</tt> is associated with a
34621 <tt>promise</tt> object, the completion of <tt>set_value()</tt> or
34622 <tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
34623 <tt>get()</tt> returns.
34633 <h3><a name="1048"></a>1048. Response to UK 335</h3>
34634 <p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34635 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34636 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
34637 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34638 <p><b>Discussion:</b></p>
34640 <p><b>Addresses UK 335</b></p>
34643 <tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
34644 association with an asynchronous result from one instance to another.
34645 However, there is no way to determine whether or not an instance has
34646 been moved from, and therefore whether or not it is safe to wait for it.
34649 <blockquote><pre>std::promise<int> p;
34650 std::unique_future<int> uf(p.get_future());
34651 std::unique_future<int> uf2(std::move(uf));
34652 uf.wait(); <font color="#C80000">// oops, uf has no result to wait for. </font>
34653 </pre></blockquote>
34656 Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
34657 (and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
34658 which returns <tt>true</tt> if there is an associated result to wait for
34659 (whether or not it is ready).
34666 <blockquote><pre>if(uf.waitable()) uf.wait();
34667 </pre></blockquote>
34676 Create an issue. Requires input from Howard. Probably NAD.
34681 Post Summit, Howard thows in his two cents:
34687 Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
34688 several years ago. At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
34691 <blockquote><pre>template <class R>
34695 typedef R result_type;
34697 future(const future&);// = delete;
34698 future& operator=(const future&);// = delete;
34700 template <class R1, class F1> friend class prommise;
34705 future(future&& f);
34706 future& operator=(future&& f);
34708 void swap(future&& f);
34710 <b>bool joinable() const;</b>
34711 bool is_normal() const;
34712 bool is_exceptional() const;
34713 bool is_ready() const;
34718 template <class ElapsedTime>
34719 bool timed_join(const ElapsedTime&);
34721 </pre></blockquote>
34724 <tt>shared_future</tt> had a similar interface. I intentionally reused
34725 the <tt>thread</tt> interface where possible to lessen the learning
34726 curve std::lib clients will be faced with.
34731 2009-10 Santa Cruz:
34736 NAD Editorial. Solved by
34737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34742 <p><b>Proposed resolution:</b></p>
34749 <h3><a name="1049"></a>1049. Response to UK 339</h3>
34750 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34751 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34752 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
34753 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
34754 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34755 <p><b>Discussion:</b></p>
34757 <p><b>Addresses UK 339</b></p>
34760 Move assignment is goiing in the wrong direction, assigning from
34761 <tt>*this</tt> to the passed rvalue, and then returning a reference to
34762 an unusable <tt>*this</tt>.
34772 Agree, move to Review.
34781 We recommend deferring this issue until after Detlef's paper (on futures)
34786 2009-10 Santa Cruz:
34791 NAD Editorial. Solved by
34792 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34797 <p><b>Proposed resolution:</b></p>
34799 Strike 30.6.5 [futures.promise] p6 and change p7:
34802 <blockquote><pre>promise& operator=(promise&& rhs);
34806 <del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
34809 -7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
34810 state.</del> <ins>associated state of <tt>*this</tt> is the same as the
34811 associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
34812 associated state.</ins>
34823 <h3><a name="1050"></a>1050. Response to UK 340</h3>
34824 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
34825 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34826 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
34827 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
34828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
34829 <p><b>Discussion:</b></p>
34831 <p><b>Addresses UK 340</b></p>
34834 There is an implied postcondition for <tt>get_future()</tt> that the state of the
34835 <tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
34836 associated state. It should be spelled out.
34846 Agree, move to Review.
34851 2009-04-03 Thomas J. Gritzan adds:
34857 <tt>promise::get_future()</tt> must not invalidate the state of the promise object.
34860 A promise is used like this:
34862 <blockquote><pre>promise<int> p;
34863 unique_future<int> f = p.get_future();
34864 <font color="#C80000">// post 'p' to a thread that calculates a value </font>
34865 <font color="#C80000">// use 'f' to retrieve the value. </font>
34866 </pre></blockquote>
34868 So <tt>get_future()</tt> must return an object that shares the same associated
34869 state with <tt>*this</tt>.
34872 But still, this function should throw an <tt>future_already_retrieved</tt> error
34873 when it is called twice.
34876 <tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
34877 was already retrieved. It should throw
34878 <tt>future_error(future_already_retrieved)</tt>, too.
34881 Suggested resolution:
34884 Replace p12/p13 30.6.5 [futures.promise]:
34888 -12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
34889 <ins>the <tt>future</tt> has already been retrieved</ins>.
34892 -13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
34893 has no associated state</del>
34894 <ins>the <tt>future</tt> associated with
34895 the associated state has already been retrieved</ins>.
34898 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
34902 Replace p14 30.6.10 [futures.task]:
34906 -14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
34907 the task</del> has already been retrieved.
34911 <i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with
34912 the task has already been retrieved.
34915 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
34925 Keep in Review status
34926 pending Detlef's forthcoming paper on futures.
34930 2009-10 Santa Cruz:
34935 NAD Editorial. Solved by
34936 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34941 <p><b>Proposed resolution:</b></p>
34943 Add after p13 30.6.5 [futures.promise]:
34946 <blockquote><pre>unique_future<R> get_future();
34953 <i>Postcondition:</i> <tt>*this</tt> has no associated state.
34964 <h3><a name="1051"></a>1051. Response to UK 279</h3>
34965 <p><b>Section:</b> 24.5.1.3.12 [reverse.iter.opindex], 24.5.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
34966 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
34967 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
34968 <p><b>Discussion:</b></p>
34970 <p><b>Addresses UK 279</b></p>
34973 The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This
34974 reasoning no longer applies as there are at least two ways to get the right
34975 return type with the new language facilities added since the previous
34980 Proposal: Specify the return type using either decltype or the Iter concept_map.
34990 Under discussion. This is a general question about all iterator
34996 Howard adds post Summit:
35001 I am requesting test cases to demonstrate a position.
35005 2009-07-24 Daniel adds:
35011 I recommend NAD. Without concepts we can no longer
35012 restrict this member in a trivial way. Using <tt>decltype</tt> the
35013 declaration would be along the lines of
35015 <blockquote><pre>static const Iter& __base(); // not defined
35016 auto operator[](difference_type n) const -> decltype(__base()[-n-1]);
35017 </pre></blockquote>
35020 but once <tt>reverse_iterator</tt> is instantiated for some given type
35021 <tt>Iter</tt> which cannot form a well-formed expression <tt>__base()[-n-1]</tt>
35022 this would cause an ill-formed function declaration, diagnostic
35023 required, and no silent SFINAE elimination.
35029 2009-10 Santa Cruz:
35038 2009-10-22 Daniel adds:
35044 IMO, my original comment regarding ill-formedness of the described
35045 construction is still correct, but I must add that I should weaken my
35046 assertion "Without concepts we can no longer restrict this member in
35051 In fact with the existence of default template arguments for function
35052 templates it is not too hard to implement this like as follows, which
35053 shows that we can indeed simulate to some sense constrained
35054 member functions in C++0x.
35058 My example does not really proof that the specification is easy, but
35059 it should be possible. I assume that the implementation would not
35060 be ABI compatible, though.
35064 It is now your own decision how to proceed ;-)
35067 <blockquote><pre>#include <type_traits>
35068 #include <cstddef>
35070 template<class T>
35071 typename std::add_rvalue_reference<T>::type declval();
35073 template<class It>
35074 struct reverse_iterator {
35077 typedef std::ptrdiff_t difference_type;
35079 template<class U = It, class Res =
35080 decltype(declval<const U&>()[declval<difference_type>()])
35082 Res operator[](difference_type n) const {
35091 reverse_iterator<int*> ri;
35093 reverse_iterator<MyIter> ri2;
35095 </pre></blockquote>
35098 The above declaration could be simplified, but the ideal solution
35101 <blockquote><pre>template<class U = It>
35102 decltype(declval<const U&>()[declval<difference_type>()])
35103 operator[](difference_type n) const;
35104 </pre></blockquote>
35107 does not work yet on gcc 4.4.1.
35115 <p><b>Proposed resolution:</b></p>
35122 <h3><a name="1052"></a>1052. Response to UK 281</h3>
35123 <p><b>Section:</b> 24.5.1.3.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
35124 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
35125 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
35126 <p><b>Discussion:</b></p>
35128 <p><b>Addresses UK 281</b></p>
35131 The current specification for return value for <tt>reverse_iterator::operator-></tt>
35132 will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
35133 iterators where the pointer type may be some kind of 'smart pointer'.
35143 <tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
35145 study group formed to come up with a suggested resolution.
35148 <tt>move_iterator</tt> solution shown in proposed wording.
35153 2009-07 post-Frankfurt:
35158 Howard to deconceptize. Move to Review after that happens.
35162 2009-08-01 Howard deconceptized:
35170 2009-10 Santa Cruz:
35176 We can't think of any reason we can't just define reverse
35177 iterator's pointer types to be the same as the underlying iterator's
35178 pointer type, and get it by calling the right arrow directly.
35181 Here is the proposed wording that was replaced:
35183 <blockquote><pre>template <class Iterator>
35184 class reverse_iterator {
35186 typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
35187 </pre></blockquote>
35190 Change 24.5.1.3.5 [reverse.iter.opref]:
35193 <blockquote><pre>pointer operator->() const;
35197 <blockquote><pre><del>&(operator*());</del>
35198 <ins>this->tmp = current;</ins>
35199 <ins>--this->tmp;</ins>
35200 <ins>return this->tmp;</ins>
35201 </pre></blockquote>
35207 2010-03-03 Daniel opens:
35215 There is a minor problem with the exposition-only declaration of the private
35216 member <tt>deref_tmp</tt> which is modified in a const member function (and the
35217 same problem occurs in the specification of <tt>operator*</tt>). The fix is to
35218 make it a mutable member.
35223 The more severe problem is that the resolution for some reasons
35224 does not explain in the rationale why it was decided to differ from
35225 the suggested fix (using <tt>deref_tmp</tt> instead of <tt>tmp</tt>) in the
35226 [ 2009-10 Santa Cruz] comment:
35229 <blockquote><pre>this->deref_tmp = current;
35230 --this->deref_tmp;
35231 return this->deref_tmp;
35232 </pre></blockquote>
35235 combined with the change of
35238 <blockquote><pre>typedef typename iterator_traits<Iterator>::pointer pointer;
35239 </pre></blockquote>
35245 <blockquote><pre>typedef Iterator pointer;
35246 </pre></blockquote>
35249 The problem of the agreed on wording is that the following rather
35250 typical example, that compiled with the wording before 1052 had
35251 been applied, won't compile anymore:
35254 <blockquote><pre>#include <iterator>
35255 #include <utility>
35258 typedef std::pair<int, double> P;
35260 std::reverse_iterator<P*> ri(&op + 1);
35261 ri->first; // Error
35263 </pre></blockquote>
35266 Comeau online returns (if a correspondingly changed
35267 <tt>reverse_iterator</tt> is used):
35270 <blockquote><pre>"error: expression must have class type
35271 return deref_tmp.operator->();
35273 detected during instantiation of "Iterator
35274 reverse_iterator<Iterator>::operator->() const [with
35275 Iterator=std::pair<int, double> *]""
35276 </pre></blockquote>
35279 Thus the change will break valid, existing code based
35280 on <tt>std::reverse_iterator</tt>.
35288 IMO the suggestion proposed in the comment is a necessary fix, which harmonizes
35289 with the similar specification of <tt>std::move_iterator</tt> and properly
35290 reflects the recursive nature of the evaluation of <tt>operator-></tt>
35295 Suggested resolution:
35302 In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator] change as indicated:
35305 <blockquote><pre>namespace std {
35306 template <class Iterator>
35307 class reverse_iterator : public
35308 iterator<typename iterator_traits<Iterator>::iterator_category,
35309 typename iterator_traits<Iterator>::value_type,
35310 typename iterator_traits<Iterator>::difference_type,
35311 <del>typename iterator_traits<</del>Iterator<del>>::pointer</del>,
35312 typename iterator_traits<Iterator>::reference> {
35315 typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
35320 <ins>mutable</ins> Iterator deref_tmp; // exposition only
35322 </pre></blockquote>
35326 Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
35328 <blockquote><pre>pointer operator->() const;
35332 1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&(operator*())</tt>.</del>
35333 <blockquote><pre><ins>deref_tmp = current;</ins>
35334 <ins>--deref_tmp;</ins>
35335 <ins>return deref_tmp;</ins>
35336 </pre></blockquote>
35353 We prefer to make to use a local variable instead of <tt>deref_tmp</tt> within
35354 <tt>operator->()</tt>. And although this means that the <tt>mutable</tt>
35355 change is no longer needed, we prefer to keep it because it is needed for
35356 <tt>operator*()</tt> anyway.
35360 Here is the proposed wording that was replaced:
35363 <blockquote class="note">
35365 Change 24.5.1.3.5 [reverse.iter.opref]:
35368 <blockquote><pre>pointer operator->() const;
35374 <blockquote><pre><del>&(operator*());</del>
35375 <ins>deref_tmp = current;
35377 return deref_tmp::operator->();</ins>
35378 </pre></blockquote>
35388 2010-03-10 Howard adds:
35394 Here are three tests that the current proposed wording passes, and no
35395 other solution I've seen passes all three:
35401 Proxy pointer support:
35403 <blockquote><pre>#include <iterator>
35404 #include <cassert>
35406 struct X { int m; };
35411 typedef std::bidirectional_iterator_tag iterator_category;
35412 typedef X& reference;
35415 pointer(X& v) : value(v) {}
35417 X* operator->() const {return &value;}
35419 typedef std::ptrdiff_t difference_type;
35420 typedef X value_type;
35421 // additional iterator requirements not important for this issue
35423 reference operator*() const { return x; }
35424 pointer operator->() const { return pointer(x); }
35425 IterX& operator--() {return *this;}
35431 std::reverse_iterator<IterX> ix;
35432 assert(&ix->m == &(*ix).m);
35434 </pre></blockquote>
35438 Raw pointer support:
35440 <blockquote><pre>#include <iterator>
35441 #include <utility>
35444 typedef std::pair<int, double> P;
35446 std::reverse_iterator<P*> ri(&op + 1);
35447 ri->first; // Error
35449 </pre></blockquote>
35453 Caching iterator support:
35455 <blockquote><pre>#include <iterator>
35456 #include <cassert>
35458 struct X { int m; };
35461 typedef std::bidirectional_iterator_tag iterator_category;
35462 typedef X& reference;
35463 typedef X* pointer;
35464 typedef std::ptrdiff_t difference_type;
35465 typedef X value_type;
35466 // additional iterator requirements not important for this issue
35468 reference operator*() const { return value; }
35469 pointer operator->() const { return &value; }
35470 IterX& operator--() {return *this;}
35478 std::reverse_iterator<IterX> ix;
35479 assert(&ix->m == &(*ix).m);
35481 </pre></blockquote>
35492 Moved to NAD Future, rationale added.
35498 <p><b>Rationale:</b></p>
35500 The LWG did not reach a consensus for a change to the WP.
35504 <p><b>Proposed resolution:</b></p>
35510 In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator] change as indicated:
35513 <blockquote><pre>namespace std {
35514 template <class Iterator>
35515 class reverse_iterator : public
35516 iterator<typename iterator_traits<Iterator>::iterator_category,
35517 typename iterator_traits<Iterator>::value_type,
35518 typename iterator_traits<Iterator>::difference_type,
35519 <del>typename iterator_traits<</del>Iterator<ins>&</ins><del>>::pointer</del>,
35520 typename iterator_traits<Iterator>::reference> {
35523 typedef <del>typename iterator_traits<</del>Iterator<ins>&</ins><del>>::pointer</del> pointer;
35528 <ins>mutable</ins> Iterator deref_tmp; // exposition only
35530 </pre></blockquote>
35534 Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
35536 <blockquote><pre>pointer operator->() const;
35540 1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&(operator*())</tt>.</del>
35541 <blockquote><pre><ins>deref_tmp = current;</ins>
35542 <ins>--deref_tmp;</ins>
35543 <ins>return deref_tmp;</ins>
35544 </pre></blockquote>
35562 <h3><a name="1053"></a>1053. Response to UK 295</h3>
35563 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
35564 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
35565 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
35566 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
35567 <p><b>Discussion:</b></p>
35569 <p><b>Addresses UK 295</b></p>
35572 There is a level of redundancy in the library specification for many
35573 algorithms that can be eliminated with the combination of concepts and
35574 default parameters for function templates. Eliminating redundancy simplified
35575 specification and reduces the risk of introducing accidental
35579 Proposed resolution: Adopt
35580 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
35590 NAD, this change would break code that takes the address of an
35596 Post Summit Alisdair adds:
35602 Request 'Open'. The issues in the paper go beyond just reducing
35603 the number of signatures, but cover unifying the idea of the ordering
35604 operation used by algorithms, containers and other library components. At
35605 least, it takes a first pass at the problem.
35609 For me (personally) that was the more important part of the paper, and not
35610 clearly addressed by the Summit resolution.
35615 2009-10 Santa Cruz:
35620 Too inventive, too late, would really need a paper. Moved to NAD Future.
35625 <p><b>Proposed resolution:</b></p>
35632 <h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
35633 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
35634 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
35635 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
35636 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
35637 <p><b>Discussion:</b></p>
35640 Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
35641 requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
35644 I have no problems leaving the WP in an inconsistent state on the best-faith
35645 assumption these concepts will be provided later, however disagree with the
35646 proposers that these constraints are not separable, orthogonal to the basic
35647 concepts of generating random number distributions.
35650 These constraints should be dropped, and applied to specific algorithms as
35654 If a more refined concept (certainly deemed useful by the proposers) is
35655 proposed there is no objection, but the basic concept should not require
35656 persistence via streaming.
35668 2009-05-31 Alisdair adds:
35674 Working on constraining the stream iterators, I have a few more observations
35675 to make on the concepts proposed while constraining the random number
35679 While I still believe the concerns are orthogonal, I don't believe the
35680 existing constraints go far enough either! The goal we want to achieve is
35681 not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
35682 operators, but that it is <tt>Serializable</tt>. I.e. there is a relationship
35683 between the insert and extract operations that guarantees to restore the
35684 state of the original object. This implies a coupling of the concepts
35685 together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
35686 assert the semantics.
35689 One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
35690 types, although we can hook a relation if we are prepared to drop down to
35691 the <tt>char</tt> type and <tt>char_traits</tt> template parameters. Doing so ties us to a
35692 form of serialization that demands implementation via the std iostreams
35693 framework, which seems overly prescriptive. I believe the goal is generally
35694 to support serialization without regard to how it is expressed - although
35695 this is getting even more inventive in terms of concepts we do not have
35701 2009-11-03 Alisdair adds:
35707 I can't find the record in the wiki minutes, but it was agreed at both
35708 Frankfurt and Santa Cruz that this issue is NAD.
35711 The agreement in SC was that I would provide you with the rationale (see
35712 below) to include when moving to NAD.
35717 2009-11-03 Howard adds:
35722 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
35726 <p><b>Proposed resolution:</b></p>
35729 <p><b>Rationale:</b></p>
35731 The issue suggests a more refined concept should be used if we want to
35732 require streaming, to separate concerns from the basic
35733 <tt>RandomNumberEngine</tt> behaviour. In Frankfurt it was observed
35734 that <tt>RandomNumberEngine</tt> <em>is</em> that more refined concept,
35735 and the basic concept used in the framework is
35736 <tt>UniformRandomNumberGenerator</tt>, which it refines.
35740 We concur, and expect this to have no repurcussions re-writing this
35741 clause now concepts are removed.
35749 <h3><a name="1057"></a>1057. <tt>RandomNumberEngineAdaptor</tt></h3>
35750 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
35751 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
35752 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
35753 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
35754 <p><b>Discussion:</b></p>
35757 The <tt>RandomNumberEngineAdaptor</tt> concept breaks precedent in the
35758 way the library has been specified by grouping requirements into a
35759 concept that is never actually used in the library.
35762 This is undoubtedly a very helpful device for documentation, but we are not
35763 comfortable with the precedent - especially as we have rejected national
35764 body comments on the same grounds.
35767 Suggest either removing the concept, or providing an algorithm/type that
35768 requires this concept in their definition (such as a factory function to
35769 create new engines).
35772 The preference is to create a single new algorithm and retain the value of
35773 the existing documentation.
35782 Walter points out that it is unlikely that any algorithm would ever
35783 require this concept, but that the concept nonetheless is useful as
35784 documentation, and (via concept maps) as a means of checking specific adapters.
35787 Alisdair disagrees as to the concept's value as documentation.
35790 Marc points out that the <tt>RandomNumberDistribution</tt>
35791 is also a concept not used elsewhere in the Standard.
35794 Pete agrees that a policy of not inventing concepts
35795 that aren't used in the Standard is a good starting point,
35796 but should not be used as a criterion for rejecting a concept.
35804 <p><b>Proposed resolution:</b></p>
35811 <h3><a name="1058"></a>1058. New container issue</h3>
35812 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
35813 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
35814 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
35815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
35816 <p><b>Discussion:</b></p>
35819 Sequence containers 23.2.3 [sequence.reqmts]:
35823 The return value of new calls added to table 83 are not specified.
35832 We agree with the proposed resolution.
35835 Move to NAD Editorial.
35840 <p><b>Proposed resolution:</b></p>
35842 Add after p6 23.2.3 [sequence.reqmts]:
35850 The iterator returned from <tt>a.insert(p,rv)</tt> points to the copy of <tt>rv</tt>
35851 inserted into <tt>a</tt>.
35854 The iterator returned from <tt>a.emplace(p, args)</tt> points to the new
35855 element constructed from <tt>args</tt> inserted into <tt>a</tt>.
35864 <h3><a name="1059"></a>1059. Usage of no longer existing FunctionType concept</h3>
35865 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
35866 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-10-23</p>
35867 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
35868 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
35869 <p><b>Discussion:</b></p>
35871 Due to a deliberate core language decision, the earlier called
35872 "foundation" concept <tt>std::FunctionType</tt> had been removed in
35873 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf">N2773</a>
35875 before the first "conceptualized" version of the WP
35876 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
35878 prepared. This caused a break of the library, which already used this
35879 concept in the adapted definition of <tt>std::function</tt>
35880 (20.8 [function.objects]/2, header <tt><functional></tt> synopsis and
35881 20.8.14.2 [func.wrap.func]).
35884 A simple fix would be to either (a) make <tt>std::function</tt>'s primary template
35885 unconstrained or to (b) add constraints based on existing (support) concepts.
35886 A more advanced fix would (c) introduce a new library concept.
35889 The big disadvantage of (a) is, that users can define templates which
35890 cause compiler errors during instantiation time because of under-constrainedness
35891 and would thus violate the basic advantage of constrained
35895 For (b), the ideal constraints for <tt>std::function</tt>'s template parameter would
35896 be one which excludes everything else but the single provided partial
35897 specialization that matches every "free function" type (i.e. any function
35898 type w/o cv-qualifier-seq and w/o ref-qualifier).
35899 Expressing such a type as as single requirement would be written as
35901 <blockquote><pre>template<typename T>
35902 requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq
35903 // or ref-qual (depending on core issue #749)
35904 && PointeeType<T> // Eliminate reference types
35905 && !ObjectType<T> // Eliminate object types
35906 </pre></blockquote>
35908 Just for completeness approach (c), which would make sense, if the
35909 library has more reasons to constrain for free function types:
35911 <blockquote><pre>auto concept FreeFunctionType<typename T>
35912 : ReferentType<T>, PointeeType<T>, MemberPointeeType<T>
35914 requires !ObjectType<T>;
35916 </pre></blockquote>
35918 I mention that approach because I expect that free function types belong
35919 to the most natural type categories for every days coders. Potential
35920 candidates in the library are <tt>addressof</tt> and class template <tt>packaged_task</tt>.
35929 Alisdair would prefer to have a core-supported <tt>FunctionType</tt> concept
35930 in order that any future changes be automatically correct
35931 without need for a library solution to catch up;
35932 he points to type traits as a precedent.
35933 Further, he believes that a published concept can't in the future
35937 Bill feels this category of entity would change sufficiently slowly
35938 that he would be willing to take the risk.
35941 Of the discussed solutions, we tend toward option (c).
35942 We like the idea of having a complete taxonomy of native types,
35943 and perhaps erred in trimming the set.
35946 We would like to have this issue reviewed by Core and would like
35947 their feedback. Move to Open.
35952 <p><b>Proposed resolution:</b></p>
35956 Change in 20.8 [function.objects]/2, Header <tt><functional></tt> synopsis:
35958 <blockquote><pre>// 20.6.16 polymorphic function wrappers:
35959 class bad_function_call;
35960 template<<del>FunctionType</del><ins>ReferentType F</ins>>
35961 <ins>requires PointeeType<F> && !ObjectType<F></ins>
35962 class function; // undefined
35963 </pre></blockquote>
35967 Change in 20.8.14.2 [func.wrap.func]:
35969 <blockquote><pre>namespace std {
35970 template<<del>FunctionType</del><ins>ReferentType F</ins>>
35971 <ins>requires PointeeType<F> && !ObjectType<F></ins>
35972 class function; // undefined
35973 </pre></blockquote>
35982 <h3><a name="1060"></a>1060. Embedded nulls in NTBS</h3>
35983 <p><b>Section:</b> 17.5.2.1.4.1 [byte.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
35984 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-10-23</p>
35985 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
35986 <p><b>Discussion:</b></p>
35989 Definition of null-terminated sequences allow for embedded nulls. This is
35990 surprising, and probably not supportable with the intended use cases.
35998 We agree with the issue, but believe this can be handled editorially.
35999 Move to NAD Editorial.
36004 <p><b>Proposed resolution:</b></p>
36011 <h3><a name="1061"></a>1061. Bad indexing for tuple access to pair (Editorial?)</h3>
36012 <p><b>Section:</b> 20.3.5.4 [pair.astuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
36013 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-10-23</p>
36014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
36015 <p><b>Discussion:</b></p>
36018 The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if
36019 given a negative integer.
36027 Move to NAD Editorial.
36032 <p><b>Proposed resolution:</b></p>
36034 20.3.5.4 [pair.astuple] p5:
36037 <blockquote><pre>template<<del>int</del> <ins>size_t</ins> I, class T1, class T2>
36038 requires True<(I < 2)>
36039 const P& get(const pair<T1, T2>&);
36049 <h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
36050 <p><b>Section:</b> 24.5.2 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
36051 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-10-23</p>
36052 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
36053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
36054 <p><b>Discussion:</b></p>
36057 It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
36058 iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
36059 container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
36060 be simple to create an iterator adapter to complete the library support.
36064 We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
36065 operations. Create a new insert iterator and factory function that inserts
36066 values into the container by calling <tt>push</tt>.
36075 Walter recommends NAD Future.
36078 Move to Open, and recommend deferring the issue until after the next
36079 Committee Draft is issued.
36084 2009-07-29 Howard moves to Tentatively NAD Future.
36089 A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
36098 Moved to NAD. The intent of these adapters are to restrict the interfaces.
36103 <p><b>Proposed resolution:</b></p>
36110 <h3><a name="1063"></a>1063. 03 iterator compatibilty</h3>
36111 <p><b>Section:</b> X [iterator.backward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
36112 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
36113 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
36114 <p><b>Discussion:</b></p>
36117 Which header must a user <tt>#include</tt> to obtain the library-supplied
36118 <tt>concept_maps</tt> declared in this paragraph?
36122 This is important information, as existing user code will break if this
36123 header is not included, and we should make a point of mandating this header
36124 is <tt>#include</tt>-d by library headers likely to make use of it, notably
36125 <tt><algorithm></tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a> for more details.
36133 We agree with the direction of the proposed resolution.
36134 Move to Tentatively Ready.
36143 We believe this is NAD Concepts, but this needs to be reviewed against the
36144 post-remove-concepts draft.
36148 <p><b>Proposed resolution:</b></p>
36149 <p><i>Change [depr.lib.iterator.primitives], Iterator primitives, as
36153 <p>To simplify the use of iterators and provide backward compatibility with
36154 previous C++ Standard Libraries,
36155 the library provides several classes and functions. <ins>Unless otherwise
36156 specified, these classes and functions shall be defined in header <tt><iterator></tt>.</ins></p>
36158 <p><i>Change X [iterator.backward], Iterator backward compatibility, as
36161 <p>The library provides concept maps that allow iterators specified with
36162 <tt>iterator_traits</tt> to interoperate with
36163 algorithms that require iterator concepts. <ins>These concept maps shall be
36164 defined in the same header that defines the iterator.</ins> [<i>Example:</i></p>
36172 <h3><a name="1064"></a>1064. Response to UK 152</h3>
36173 <p><b>Section:</b> 17.3.18 [defns.obj.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
36174 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
36175 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
36176 <p><b>Discussion:</b></p>
36178 <p><b>Addresses UK 152</b></p>
36181 Object state is using a definition of object (instance of a class) from
36182 outside the standard, rather than the 'region of storage' definiton in
36183 1.8 [intro.object]p1
36191 We think we're removing this; See X [func.referenceclosure.cons].
36195 2009-10 Santa Cruz:
36200 Mark as NAD. This will not affect user or implementer code
36205 <p><b>Proposed resolution:</b></p>
36214 <h3><a name="1067"></a>1067. simplified wording for inner_product</h3>
36215 <p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
36216 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-17 <b>Last modified:</b> 2010-10-23</p>
36217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
36218 <p><b>Discussion:</b></p>
36221 One of the motivating examples for introducing requirements-aliases was to
36222 simplify the wording of the <tt>inner_product</tt> requirements. As the paper
36223 adopting the feature and constrained wording for the library went through in
36224 the same meeting, it was not possible to make the change at the time. The
36225 simpler form should be adopted now though. Similarly, most the other
36226 numerical algorithms can benefit from a minor cleanup.
36229 Note that in each case, the second more generalised form of the algorithm
36230 does not benefit, as there are already named constraints supplied by the
36231 template type parameters.
36235 2009-05-02 Daniel adds:
36241 one part of the suggested resolution suggests the removal of the
36242 <tt>MoveConstructible<T></tt> requirement from
36243 <tt>inner_product</tt>. According to 26.7.2 [inner.product]
36247 Computes its result by initializing the accumulator <tt>acc</tt> with the
36248 initial value <tt>init</tt>
36252 this step requires at least <tt>MoveConstructible</tt>.
36256 Therefore I strongly suggest to take this removal back (Note also
36257 that the corresponding overload with a functor argument still has
36258 the same <tt>MoveConstructible<T></tt> requirement).
36268 We agree with the proposed resolution as amended by Daniel's suggestion
36269 to restore <tt>MoveConstructible</tt>,
36270 reflected in the updated proposed resolution below.
36273 Move to Tentatively Ready.
36278 <p><b>Proposed resolution:</b></p>
36280 Change in 26.7 [numeric.ops] and 26.7.1 [accumulate]:
36283 <blockquote><pre>template <InputIterator Iter, MoveConstructible T>
36284 requires <ins>add =</ins> HasPlus<T, Iter::reference>
36285 && HasAssign<T, <del>HasPlus<T, Iter::reference></del> <ins>add</ins>::result_type>
36286 T accumulate(Iter first, Iter last, T init);
36287 </pre></blockquote>
36290 Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
36293 <blockquote><pre>template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T>
36294 requires <ins>mult =</ins> HasMultiply<Iter1::reference, Iter2::reference>
36295 && <ins>add =</ins> HasPlus<T, <del>HasMultiply<Iter1::reference, Iter2::reference></del> <ins>mult</ins>::result_type>
36296 && HasAssign<
36299 HasMultiply<Iter1::reference, Iter2::reference>::result_type></del> <ins>add</ins>::result_type>
36300 T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
36301 </pre></blockquote>
36304 Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
36307 <blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
36308 requires <ins>add =</ins> HasPlus<InIter::value_type, InIter::reference>
36309 && HasAssign<InIter::value_type,
36310 <del>HasPlus<InIter::value_type, InIter::reference></del> <ins>add</ins>::result_type>
36311 && Constructible<InIter::value_type, InIter::reference>
36312 OutIter partial_sum(InIter first, InIter last, OutIter result);
36313 </pre></blockquote>
36316 Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
36319 <blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
36320 requires <ins>sub =</ins> HasMinus<InIter::value_type, InIter::value_type>
36321 && Constructible<InIter::value_type, InIter::reference>
36322 && OutputIterator<OutIter, <del>HasMinus<InIter::value_type, InIter::value_type></del> <ins>sub</ins>::result_type>
36323 && MoveAssignable<InIter::value_type>
36324 OutIter adjacent_difference(InIter first, InIter last, OutIter result);
36325 </pre></blockquote>
36333 <h3><a name="1068"></a>1068. class random_device should be movable</h3>
36334 <p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
36335 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2010-10-23</p>
36336 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
36337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
36338 <p><b>Discussion:</b></p>
36341 class <tt>random_device</tt> should be movable.
36349 Move to Open, and recommend this issue be deferred until after the next
36350 Committee Draft is issued.
36354 2009-10 post-Santa Cruz:
36359 Leave open. Walter to provide drafting as part of his planned paper.
36363 2010 Pittsburgh: Moved to NAD.
36369 <p><b>Rationale:</b></p>
36371 WP is correct as written.
36375 <p><b>Proposed resolution:</b></p>
36382 <h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
36383 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
36384 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2010-10-23</p>
36385 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
36386 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
36387 <p><b>Discussion:</b></p>
36390 class <tt>seed_seq</tt> should support efficient move operations.
36398 Move to Open, and recommend this issue be deferred until after the next
36399 Committee Draft is issued.
36403 2009-10 post-Santa Cruz:
36408 Leave open. Walter to provide drafting as part of his planned paper.
36417 <tt>seed_seq</tt> is explicitly not copyable, so, much like LWG issue
36418 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, LWG issue 1069 could be marked NAD to be consistent
36424 <p><b>Proposed resolution:</b></p>
36431 <h3><a name="1072"></a>1072. Is std::hash a constrained template or not?</h3>
36432 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
36433 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
36434 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
36435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
36436 <p><b>Discussion:</b></p>
36439 Is <tt>std::hash</tt> a constrained template or not?
36442 According to Class template hash 20.8.15 [unord.hash], the definition is:
36445 <blockquote><pre>template <class T>
36446 struct hash : public std::unary_function<T, std::size_t> {
36447 std::size_t operator()(T val) const;
36449 </pre></blockquote>
36452 And so unconstrained.
36455 According to the <tt><functional></tt> synopsis in p2 Function objects
36456 20.8 [function.objects] the template is declared as:
36459 <blockquote><pre>template <ReferentType T> struct hash;
36460 </pre></blockquote>
36463 which would make hash a constrained template.
36467 2009-03-22 Daniel provided wording.
36477 Alisdair is not certain that Daniel's proposed resolution is sufficient,
36478 and recommends we leave the hash template unconstrained for now.
36481 Recommend that the Project Editor make the constrained declaration consistent
36482 with the definition in order to make the Working Paper internally consistent,
36483 and that the issue then be revisited.
36491 <p><b>Proposed resolution:</b></p>
36494 [To the editor: This resolution is merge-compatible to the
36495 resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>]
36501 In 20.8 [function.objects]/2, header <tt><functional></tt> synopsis, change as indicated:
36504 <blockquote><pre>// 20.6.17, hash function base template:
36505 template <ReferentType T> struct hash; <ins>// undefined</ins>
36506 </pre></blockquote>
36510 In 20.8.15 [unord.hash]/1 change as indicated:
36512 <blockquote><pre>namespace std {
36513 <del>template <class T>
36514 struct hash : public std::unary_function<T, std::size_t> {
36515 std::size_t operator()(T val) const;
36517 <ins>template <ReferentType T> struct hash; // undefined</ins>
36519 </pre></blockquote>
36523 In 20.8.15 [unord.hash]/2 change as indicated:
36527 -2- <ins>For all library-provided specializations, the template
36528 instantiation <tt>hash<T></tt>
36529 shall provide a public <tt>operator()</tt> with return type <tt>std::size_t</tt> to
36530 satisfy the concept
36531 requirement <tt>Callable<const hash<T>, const T&></tt>. If <tt>T</tt> is an object
36532 type or reference to
36533 object, <tt>hash<T></tt> shall be publicly derived from
36534 <tt>std::unary_function<T, std::size_t></tt>.
36535 </ins> The return value of <tt>operator()</tt> is unspecified, except that
36537 shall yield the same result. <tt>operator()</tt> shall not throw exceptions.
36542 In 18.7 [support.rtti]/1, header <tt><typeinfo></tt> synopsis change as indicated:
36544 <blockquote><pre>namespace std {
36547 template <<del>class</del><ins>ReferentType</ins> T> struct hash;
36548 </pre></blockquote>
36557 <h3><a name="1074"></a>1074. concept map broken by N2840</h3>
36558 <p><b>Section:</b> X [allocator.element.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
36559 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
36560 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
36561 <p><b>Discussion:</b></p>
36564 p7 Allocator-related element concepts X [allocator.element.concepts]
36568 The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt>
36569 specialization no longer matches the original concept:
36572 <blockquote><pre>template <Allocator Alloc, class T, class ... Args>
36573 requires HasConstructor<T, Args...>
36574 concept_map AllocatableElement<Alloc, T, Args&&...> {
36575 void construct_element(Alloc& a, T* t, Args&&... args) {
36576 Alloc::rebind<T>(a).construct(t, forward(args)...);
36579 </pre></blockquote>
36582 2009-03-23 Pablo adds:
36587 Actually, this is incorrect,
36588 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
36590 X [allocator.element.concepts] paragraph 8, modify the definition of the
36591 <tt>AllocatableElement</tt> concept and eliminate the related concept map:" but
36592 then neglects to include the red-lined text of the concept map that was
36593 to be eliminated. Pete also missed this, but I caught it he asked me to
36594 review his edits. Pete's updated WP removes the concept map entirely,
36595 which was the original intent. The issue is, therefore, moot. Note, as
36596 per my presentation of
36597 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
36598 in summit, <tt>construct()</tt> no longer has a
36599 default implementation. This regrettable fact was deemed (by David
36600 Abrahams, Doug, and myself) to be preferable to the complexity of
36601 providing a default implementation that would not under-constrain a more
36602 restrictive allocator (like the scoped allocators).
36606 2009-05-01 Daniel adds:
36611 it seems to me that #1074 should be resolved as a NAD, because the
36612 current WP has already removed the previous AllocatableElement concept map.
36613 It introduced auto concept AllocatableElement instead, but as of
36614 X [allocator.element.concepts]/7 this guy contains now
36616 <blockquote><pre>requires FreeStoreAllocatable<T>;
36617 void Alloc::construct(T*, Args&&...);
36618 </pre></blockquote>
36627 The affected code is no longer part of the Working Draft.
36635 <p><b>Proposed resolution:</b></p>
36637 Change X [allocator.element.concepts]:
36640 <blockquote><pre>template <Allocator Alloc, class T, class ... Args>
36641 requires HasConstructor<T, Args...>
36642 concept_map AllocatableElement<Alloc, T, Args&&...> {
36643 void construct_element(<del>Alloc& a,</del> T* t, Args&&... args) {
36644 Alloc::rebind<T>(a).construct(t, forward(args)...);
36647 </pre></blockquote>
36655 <h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
36656 <p><b>Section:</b> 20.8.9 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
36657 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-10-23</p>
36658 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
36659 <p><b>Discussion:</b></p>
36661 The class templates <tt>unary/binary_negate</tt> need constraining and move support.
36664 Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
36665 also be deprecated. However, until a generic negate adaptor is introduced
36666 that can negate any <tt>Callable</tt> type, they must be supported so should be
36667 constrained. Likewise, they should be movable, and support adopting a
36668 move-only predicate type.
36671 In order to preserve ABI compatibility, new rvalue overloads are supplied in
36672 preference to changing the existing pass-by-const-ref to pass-by-value.
36675 Do not consider the issue of forwarding mutable lvalues at this point,
36676 although remain open to another issue on the topic.
36680 2009-05-01 Daniel adds:
36685 IMO the currently proposed resolution needs some updates
36686 because it is ill-formed at several places:
36692 In concept AdaptableUnaryFunction change
36694 <blockquote><pre>typename X::result_type;
36695 typename X::argument_type;
36696 </pre></blockquote>
36700 <blockquote><pre>Returnable result_type = typename X::result_type;
36701 typename argument_type = typename X::argument_type;
36702 </pre></blockquote>
36704 [The replacement "Returnable result_type" instead of "typename
36705 result_type" is non-editorial, but maybe you prefer that as well]
36710 In concept AdaptableBinaryFunction change
36712 <blockquote><pre>typename X::result_type;
36713 typename X::first_argument_type;
36714 typename X::second_argument_type;
36715 </pre></blockquote>
36719 <blockquote><pre>Returnable result_type = typename X::result_type;
36720 typename first_argument_type = typename X::first_argument_type;
36721 typename second_argument_type = typename X::second_argument_type;
36722 </pre></blockquote>
36724 [The replacement "Returnable result_type" instead of "typename
36725 result_type" is non-editorial, but maybe you prefer that as well.]
36731 In class unary/binary_function
36735 I suggest to change "ReturnType" to "Returnable" in both cases.
36738 I think you want to replace the remaining occurrences of "Predicate" by "P"
36739 (in both classes in copy/move from a predicate)
36745 I think you need to change the proposed signatures of not1 and not2, because
36746 they would still remain unconstrained: To make them constrained at least a
36747 single requirement needs to be added to enable requirement implication. This
36748 could be done via a dummy ("requires True<true>") or just explicit as follows:
36752 <blockquote><pre>template <AdaptableUnaryFunction P>
36753 requires Predicate< P, P::argument_type>
36754 unary_negate<P> not1(const P&& pred);
36755 template <AdaptableUnaryFunction P>
36756 requires Predicate< P, P::argument_type >
36757 unary_negate<P> not1(P&& pred);
36760 -3- Returns: unary_negate<P>(pred).
36764 [Don't we want a move call for the second overload as in
36766 <blockquote><pre>unary_negate<P>(std::move(pred))
36767 </pre></blockquote>
36769 in the Returns clause ?]
36773 <pre>template <AdaptableBinaryFunction P>
36774 requires Predicate< P, P::first_argument_type, P::second_argument_type >
36775 binary_negate<P> not2(const P& pred);
36776 template <AdaptableBinaryFunction P>
36777 requires Predicate< P, P::first_argument_type, P::second_argument_type >
36778 binary_negate<P> not2(P&& pred);
36781 -5- Returns: binary_negate<P>(pred).
36784 [Don't we want a move call for the second overload as in
36786 <blockquote><pre>binary_negate<P>(std::move(pred))
36787 </pre></blockquote>
36789 in the Returns clause ?]
36803 There is concern that complicating the solution
36804 to preserve the ABI seems unnecessary,
36805 since we're not in general preserving the ABI.
36808 We would prefer a separate paper consolidating all Clause 20
36809 issues that are for the purpose of providing constrained versions
36810 of the existing facilities.
36818 2009-10 post-Santa Cruz:
36823 Leave open pending the potential move constructor paper. Note that
36824 we consider the "constraining" part NAD Concepts.
36828 2010-01-31 Alisdair removes the current proposed wording from the proposed
36829 wording section because it is based on concepts. That wording is proposed here:
36833 <blockquote class="note">
36835 Add new concepts where appropriate::
36838 <blockquote><pre>auto concept AdaptableUnaryFunction< typename X > {
36839 typename X::result_type;
36840 typename X::argument_type;
36843 auto concept AdaptableBinaryFunction< typename X > {
36844 typename X::result_type;
36845 typename X::first_argument_type;
36846 typename X::second_argument_type;
36848 </pre></blockquote>
36855 Base X [base] (Only change is constrained Result)
36860 -1- The following classes are provided to simplify the typedefs of the
36861 argument and result types:
36863 <pre>namespace std {
36864 template <class Arg, <del>class</del> <ins>ReturnType</ins> Result>
36865 struct unary_function {
36866 typedef Arg argument_type;
36867 typedef Result result_type;
36870 template <class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result>
36871 struct binary_function {
36872 typedef Arg1 first_argument_type;
36873 typedef Arg2 second_argument_type;
36874 typedef Result result_type;
36877 </pre></blockquote>
36880 Negators 20.8.9 [negators]:
36885 -1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
36886 respectively, and return their complements (5.3.1).
36889 <pre>template <<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>>
36890 <ins>requires Predicate< P, P::argument_type ></ins>
36892 : public unary_function<<del>typename</del> P<del>redicate</del>::argument_type,bool> {
36894 <ins>unary_negate(const unary_negate & ) = default;</ins>
36895 <ins>unary_negate(unary_negate && );</ins>
36897 <ins>requires CopyConstructible< P ></ins>
36898 explicit unary_negate(const Predicate& pred);
36899 <ins>requires MoveConstructible< P >
36900 explicit unary_negate(Predicate && pred);</ins>
36902 bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type& x) const;
36906 -2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
36909 <pre>template <class Predicate>
36910 unary_negate<Predicate> not1(const Predicate&amp; pred);
36911 <ins>template <class Predicate>
36912 unary_negate<Predicate> not1(Predicate&& pred);</ins>
36915 -3- <i>Returns:</i> <tt>unary_negate<Predicate>(pred)</tt>.
36918 <pre>template <<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> >
36919 <ins>requires Predicate< P, P::first_argument_type, P::second_argument_type ></ins>
36920 class binary_negate
36921 : public binary_function<<del>typename</del> P<del>redicate</del>::first_argument_type,
36922 <del>typename</del> P<del>redicate</del>::second_argument_type, bool> {
36924 <ins>biary_negate(const binary_negate & ) = default;</ins>
36925 <ins>binary_negate(binary_negate && );</ins>
36927 <ins>requires CopyConstructible< P ></ins>
36928 explicit binary_negate(const Predicate& pred);
36929 <ins>requires MoveConstructible< P >
36930 explicit binary_negate(const Predicate& pred);</ins>
36932 bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type& x,
36933 const <del>typename</del> P<del>redicate</del>::second_argument_type& y) const;
36937 -4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
36940 <pre>template <class Predicate>
36941 binary_negate<Predicate> not2(const Predicate& pred);
36942 <ins>template <class Predicate>
36943 binary_negate<Predicate> not2(Predicate&& pred);</ins>
36947 -5- <i>Returns:</i> <tt>binary_negate<Predicate>(pred)</tt>.
36960 Move to NAD Concepts. The move-semantic part has been addressed by a core language change, which implicitly generates appropriate move constructors and move-assignment operators.
36965 <p><b>Proposed resolution:</b></p>
36972 <h3><a name="1077"></a>1077. Nonesense <tt>tuple</tt> declarations</h3>
36973 <p><b>Section:</b> 20.4.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
36974 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-10-23</p>
36975 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
36976 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
36977 <p><b>Discussion:</b></p>
36979 Class template tuple 20.4.2 [tuple.tuple]:
36982 <blockquote><pre>template <class... UTypes>
36983 requires Constructible<Types, const UTypes&>...
36984 template <class... UTypes>
36985 requires Constructible<Types, RvalueOf<UTypes>::type>...
36986 </pre></blockquote>
36989 Somebody needs to look at this and say what it should be.
36993 2009-03-21 Daniel provided wording.
37002 The resolution looks correct; move to NAD Editorial.
37006 <p><b>Proposed resolution:</b></p>
37008 In 20.4.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated:
37011 <blockquote><pre>template <class... UTypes>
37012 requires Constructible<Types, const UTypes&>...
37013 <ins>tuple(const pair<UTypes...>&);</ins>
37014 template <class... UTypes>
37015 requires Constructible<Types, RvalueOf<UTypes>::type>...
37016 <ins>tuple(pair<UTypes...>&&);</ins>
37017 </pre></blockquote>
37020 [NB.: The corresponding prototypes do already exist in 20.4.2.1 [tuple.cnstr]/7+8]
37028 <h3><a name="1078"></a>1078. DE-17: Remove class type_index</h3>
37029 <p><b>Section:</b> 20.13 [type.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37030 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-10-23</p>
37031 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37032 <p><b>Discussion:</b></p>
37034 <p><b>Addresses DE 17</b></p>
37040 The class <tt>type_index</tt> should be removed; it provides no additional
37041 functionality beyond providing appropriate concept maps.
37045 2009-03-31 Peter adds:
37051 It is not true, in principle, that <tt>std::type_index</tt> provides no utility
37052 compared to bare <tt>std::type_info*</tt>.
37055 <tt>std::type_index</tt> can avoid the lifetime issues with <tt>type_info</tt> when the
37056 DLL that has produced the <tt>type_info</tt> object is unloaded. A raw
37057 <tt>type_info*</tt> does not, and cannot, provide any protection in this case.
37058 A <tt>type_index</tt> can (if the implementor so chooses) because it can wrap a
37059 smart (counted or even cloning) pointer to the <tt>type_info</tt> data that is
37060 needed for <tt>name()</tt> and <tt>before()</tt> to work.
37066 <p><b>Proposed resolution:</b></p>
37067 <p>Modify the header <typeinfo> synopsis in
37068 18.7 [support.rtti]p1 as follows:</p>
37070 <blockquote><pre>namespace std {
37072 <del>class type_index;</del>
37073 template <class T> struct hash;
37074 template<> struct hash<<del>type_index</del><ins>const type_info *</ins>> : public std::unary_function<<del>type_index</del><ins>const type_info *</ins>, size_t> {
37075 size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const;
37077 <ins>concept_map LessThanComparable<const type_info *> <i>see below</i></ins>
37081 </pre></blockquote>
37083 <p>Add the following new subsection</p>
37086 <ins>18.7.1.1 Template specialization <code>hash<const type_info *></code>
37087 [type.info.hash]</ins></p>
37089 <pre><ins>size_t operator()(const type_info *x) const;</ins>
37092 <li><ins><i>Returns</i>: <code>x->hash_code()</code></ins></li>
37096 <p>Add the following new subsection</p>
37098 <p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p>
37101 <pre><ins>concept_map LessThanComparable<const type_info *> {</ins>
37102 <ins>bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }</ins>
37103 <ins>bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }</ins>
37104 <ins>bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }</ins>
37105 <ins>bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }</ins>
37109 <li><ins><i>Note</i>: provides a well-defined ordering among
37110 <code>type_info const</code> pointers, which makes such pointers
37111 usable in associative containers (23.4).</ins></li>
37115 <p>Remove section 20.13 [type.index]</p>
37122 <h3><a name="1080"></a>1080. Concept ArithmeticLike should provide explicit boolean conversion</h3>
37123 <p><b>Section:</b> X [concept.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37124 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2010-10-23</p>
37125 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37126 <p><b>Discussion:</b></p>
37128 Astonishingly, the current concept ArithmeticLike as specified in
37129 X [concept.arithmetic] does not provide explicit conversion
37130 to <tt>bool</tt> although this is a common property of arithmetic types
37131 (4.12 [conv.bool]). Recent proposals that introduced such types
37132 (integers of arbitrary precision,
37133 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2143.pdf">n2143</a>,
37135 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a>
37137 via conversion to <tt>long long</tt>) also took care of such a feature.
37140 Adding such an explicit conversion associated function would also
37141 partly solve a currently invalid effects clause in library, which bases
37142 on this property, 24.2.7 [random.access.iterators]/2:
37144 <blockquote><pre>{ difference_type m = n;
37145 if (m >= 0) while (m--) ++r;
37146 else while (m++) --r;
37148 </pre></blockquote>
37151 Both while-loops take advantage of a contextual conversion to <tt>bool</tt>
37152 (Another problem is that the >= comparison uses the no
37153 longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>).
37156 <b>Original proposed resolution:</b>
37160 In X [concept.arithmetic], add to the list of less refined
37161 concepts one further concept:
37164 <blockquote><pre>concept ArithmeticLike<typename T>
37165 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
37166 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
37167 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
37168 HasPostdecrement<T>,
37169 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
37170 HasMultiplyAssign<T, const T&>,
37171 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
37172 </pre></blockquote>
37176 In 24.2.7 [random.access.iterators]/2 change the current effects clause
37177 as indicated [The proposed insertion fixes the problem that the previous
37178 implicit construction from integrals has been changed to an explicit
37181 <blockquote><pre>{ difference_type m = n;
37182 if (m >= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r;
37183 else while (m++) --r;
37185 </pre></blockquote>
37195 We agree that arithmetic types ought be convertible to <tt>bool</tt>,
37196 and we therefore agree with the proposed resolution's paragraph 1.
37199 We do not agree that the cited effects clause is invalid,
37200 as it expresses intent rather than specific code.
37203 Move to Review, pending input from concepts experts.
37209 <p><b>Proposed resolution:</b></p>
37211 In X [concept.arithmetic], add to the list of less refined
37212 concepts one further concept:
37215 <blockquote><pre>concept ArithmeticLike<typename T>
37216 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
37217 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
37218 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
37219 HasPostdecrement<T>,
37220 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
37221 HasMultiplyAssign<T, const T&>,
37222 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
37223 </pre></blockquote>
37230 <h3><a name="1081"></a>1081. Response to UK 216</h3>
37231 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37232 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37233 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
37234 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37235 <p><b>Discussion:</b></p>
37236 <p><b>Addresses UK 216, JP 46, JP 48</b></p>
37239 All the containers use concepts for their iterator usage, exect for
37240 <tt>basic_string</tt>. This needs fixing.
37244 Use concepts for iterator template parameters throughout the chapter.
37252 NB comments to be handled by Dave Abrahams and Howard Hinnant with
37253 advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies
37254 extensive proposed wording; start there.
37258 <p><b>Proposed resolution:</b></p>
37265 <h3><a name="1082"></a>1082. Response to JP 49</h3>
37266 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37267 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37268 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
37269 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37270 <p><b>Discussion:</b></p>
37271 <p><b>Addresses JP 49</b></p>
37274 <tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt>
37275 concept and change as follows.
37278 <blockquote><pre>template<CodeConvert Codecvt, class Elem = wchar_t>
37279 class wstring_convert {
37280 </pre></blockquote>
37287 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
37291 <p><b>Proposed resolution:</b></p>
37298 <h3><a name="1083"></a>1083. Response to JP 52, 53</h3>
37299 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37300 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37301 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
37302 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37303 <p><b>Discussion:</b></p>
37304 <p><b>Addresses JP 52, JP 53</b></p>
37307 <tt>InputIterator</tt> does not use concept.
37311 <tt>OutputIterator</tt> does not use concept.
37315 Comments include proposed wording.
37323 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
37327 <p><b>Proposed resolution:</b></p>
37334 <h3><a name="1084"></a>1084. Response to UK 250</h3>
37335 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37336 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37337 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
37338 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37339 <p><b>Discussion:</b></p>
37340 <p><b>Addresses UK 250</b></p>
37343 A default implementation should be supplied for the post-increment
37344 operator to simplify implementation of iterators by users.
37348 Copy the Effects clause into the concept description as the default
37349 implementation. Assumes a default value for postincrement_result
37357 Howard will open an issue.
37361 2009-06-07 Daniel adds:
37366 This issue cannot currently be resolved as suggested, because
37367 that would render auto-detection of the return type
37368 <tt>postincrement_result</tt> invalid, see [concept.map.assoc]/4+5. The
37369 best fix would be to add a default type to that associated type, but
37370 unfortunately any default type will prevent auto-deduction of types of
37371 associated functions as quoted above. A corresponding core issue
37376 <p><b>Proposed resolution:</b></p>
37378 This wording assumes the acceptance of UK 251 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>. Both
37379 wordings change the same paragraphs.
37384 Change 24.2.5 [forward.iterators]:
37388 <pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
37390 MoveConstructible postincrement_result;
37391 requires HasDereference<postincrement_result>
37392 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
37394 postincrement_result operator++(X& r, int)<del>;</del> <ins>{
37400 axiom MultiPass(X a, X b) {
37401 if (a == b) *a == *b;
37402 if (a == b) ++a == ++b;
37405 </pre></blockquote>
37413 <h3><a name="1085"></a>1085. Response to UK 258</h3>
37414 <p><b>Section:</b> 24.2.6 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37415 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37416 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
37417 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37418 <p><b>Discussion:</b></p>
37419 <p><b>Addresses UK 258</b></p>
37422 A default implementation should be supplied for the post-decrement
37423 operator to simplify implementation of iterators by users.
37427 Copy the Effects clause into the concept description as the default
37428 implementation. Assumes a default value for postincrement_result
37436 Howard will open an issue.
37440 2009-06-07 Daniel adds:
37445 This issue cannot currently be resolved as suggested, because
37446 that would render auto-detection of the return type
37447 <tt>postdecrement_result</tt> invalid, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>.
37451 <p><b>Proposed resolution:</b></p>
37454 Change 24.2.6 [bidirectional.iterators]:
37458 <pre>concept BidirectionalIterator<typename X> : ForwardIterator<X> {
37459 MoveConstructible postdecrement_result;
37460 requires HasDereference<postdecrement_result>
37461 && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&>
37462 && Convertible<postdecrement_result, const X&>;
37463 X& operator--(X&);
37464 postdecrement_result operator--(X& <ins>r</ins>, int)<del>;</del> <ins>{
37470 </pre></blockquote>
37478 <h3><a name="1086"></a>1086. Response to UK 284</h3>
37479 <p><b>Section:</b> 24.6 [stream.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37480 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37481 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37482 <p><b>Discussion:</b></p>
37483 <p><b>Addresses UK 284</b></p>
37486 The stream iterators need constraining with concepts/requrires clauses.
37494 We agree. To be handled by Howard, Martin and PJ.
37498 <p><b>Proposed resolution:</b></p>
37505 <h3><a name="1087"></a>1087. Response to UK 301</h3>
37506 <p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37507 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
37509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37510 <p><b>Discussion:</b></p>
37511 <p><b>Addresses UK 301</b></p>
37514 <tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator<Iter,
37515 Iter::reference></tt> Which implies they need to copy some values in the
37516 range the algorithm is iterating over. This is not however the case, the
37517 only thing that happens is <tt>const T&</tt>s might be copied over existing
37518 elements (hence the <tt>OutputIterator<Iter, const T&></tt>.
37522 Remove <tt>OutputIterator<Iter, Iter::reference></tt> from <tt>replace</tt>
37523 and <tt>replace_if</tt>.
37531 We agree. To be handled by Howard.
37535 <p><b>Proposed resolution:</b></p>
37537 Change in [algorithms.syn] and 25.3.5 [alg.replace]:
37540 <blockquote><pre>template<ForwardIterator Iter, class T>
37541 requires <del>OutputIterator<Iter, Iter::reference>
37542 &&</del> OutputIterator<Iter, const T&>
37543 && HasEqualTo<Iter::value_type, T>
37544 void replace(Iter first, Iter last,
37545 const T& old_value, const T& new_value);
37547 template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
37548 requires <del>OutputIterator<Iter, Iter::reference>
37549 &&</del> OutputIterator<Iter, const T&>
37550 && CopyConstructible<Pred>
37551 void replace_if(Iter first, Iter last,
37552 Pred pred, const T& new_value);
37553 </pre></blockquote>
37560 <h3><a name="1088"></a>1088. Response to UK 342</h3>
37561 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
37562 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37563 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
37564 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
37565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
37566 <p><b>Discussion:</b></p>
37567 <p><b>Addresses UK 342</b></p>
37570 <tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
37571 inconsistent with other types that provide a <tt>swap</tt> member function.
37575 Add a non-member overload <tt>void swap(promise&& x,promise&& y){ x.swap(y); }</tt>
37583 Create an issue. Move to review, attention: Howard. Detlef will also
37588 Post Summit Daniel provided wording.
37593 2009-10 Santa Cruz:
37598 NAD Editorial. Solved by
37599 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
37604 <p><b>Proposed resolution:</b></p>
37608 In 30.6.5 [futures.promise], before p.1, immediately after class template
37611 <blockquote><pre><ins>
37612 template <class R>
37613 void swap(promise<R>& x, promise<R>& y);
37615 </pre></blockquote>
37619 Change 30.6.5 [futures.promise]/10 as indicated (to fix a circular definition):
37623 -10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
37624 of <tt>*this</tt> and <tt>other</tt></ins>
37627 <ins><i>Throws:</i> Nothing.</ins>
37633 After the last paragraph in 30.6.5 [futures.promise] add the following
37634 prototype description:
37636 <blockquote><pre><ins>
37637 template <class R>
37638 void swap(promise<R>& x, promise<R>& y);
37642 <ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
37645 <ins><i>Throws:</i> Nothing.</ins>
37659 <h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>, missing non-member <tt>swap</tt></h3>
37660 <p><b>Section:</b> 30.6.10 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
37661 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37662 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.task">issues</a> in [futures.task].</p>
37663 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
37664 <p><b>Discussion:</b></p>
37666 Class template <tt>packaged_task</tt> in 30.6.10 [futures.task] shows a member <tt>swap</tt>
37667 declaration, but misses to
37668 document it's effects (No prototype provided). Further on this class
37669 misses to provide a non-member
37679 Alisdair notes that paragraph 2 of the proposed resolution has already been
37680 applied in the current Working Draft.
37683 We note a pending <tt>future</tt>-related paper by Detlef;
37684 we would like to wait for this paper before proceeding.
37692 2009-05-24 Daniel removed part 2 of the proposed resolution.
37697 2009-10 post-Santa Cruz:
37702 Move to Tentatively Ready, removing bullet 3 from the proposed
37703 resolution but keeping the other two bullets.
37712 Moved to NAD Editorial. Rationale added below.
37717 <p><b>Rationale:</b></p>
37723 <p><b>Proposed resolution:</b></p>
37727 In 30.6.10 [futures.task], immediately after the definition of class
37728 template packaged_task add:
37730 <blockquote><pre><ins>
37731 template<class R, class... Argtypes>
37732 void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&);
37734 </pre></blockquote>
37742 At the end of 30.6.10 [futures.task] (after p. 20), add add the following
37743 prototype description:
37746 <blockquote><pre><ins>
37747 template<class R, class... Argtypes>
37748 void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y);
37752 <i>Effects:</i> <tt>x.swap(y)</tt>
37755 <i>Throws:</i> Nothing.
37767 <h3><a name="1091"></a>1091. Multimap description confusing</h3>
37768 <p><b>Section:</b> 23.6.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
37769 <b>Submitter:</b> LWG <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
37771 <p><b>Discussion:</b></p>
37773 <p><b>Addresses UK 246</b></p>
37775 The content of this sub-clause is purely trying to describe in words the
37776 effect of the requires clauses on these operations, now that we have
37777 Concepts. As such, the description is more confusing than the signature
37778 itself. The semantic for these functions is adequately covered in the
37779 requirements tables in 23.2.4 [associative.reqmts].
37788 Pete is clearly right that
37789 this one is technical rather than editorial.
37798 We agree with the proposed resolution.
37806 2009-10 Santa Cruz:
37811 Mark as NAD, solved by removing concepts.
37816 <p><b>Proposed resolution:</b></p>
37818 Strike 23.6.2.2 [multimap.modifiers] entirely
37819 (but do NOT strike these signatures from the class template definition!).
37827 <h3><a name="1092"></a>1092. Class template <tt>integral_constant</tt> should be a constrained template</h3>
37828 <p><b>Section:</b> 20.7.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
37829 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37830 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
37831 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
37832 <p><b>Discussion:</b></p>
37834 A first step to change the type traits predicates to constrained templates is to
37835 constrain their common base template <tt>integral_constant</tt>. This can be done,
37836 without enforcing depending classes to be constrained as well, but not
37838 without brute force <tt>late_check</tt> usages. The following proposed resolution depends
37839 on the resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.
37847 Move to Open, pending a paper that looks at constraints
37848 for the entirety of the type traits
37849 and their relationship to the foundation concepts.
37850 We recommend this be deferred
37851 until after the next Committee Draft is issued.
37855 <p><b>Proposed resolution:</b></p>
37859 In 20.7.2 [meta.type.synop], Header <tt><type_traits></tt>
37860 synopsis change as indicated:
37862 <blockquote><pre>namespace std {
37863 // 20.5.3, helper class:
37864 template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> struct integral_constant;
37865 </pre></blockquote>
37869 In 20.7.3 [meta.help] change as indicated:
37871 <blockquote><pre>template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v>
37872 struct integral_constant {
37873 static constexpr T value = v;
37874 typedef T value_type;
37875 typedef integral_constant<T,v> type;
37876 constexpr operator value_type() { return value; }
37878 </pre></blockquote>
37887 <h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
37888 <p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
37889 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
37890 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
37891 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
37892 <p><b>Discussion:</b></p>
37895 There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
37896 algorithm accepting a random number engine.
37901 The Iterators must be shuffle iterators, yet this requirement is missing.
37904 The <tt>RandomNumberEngine</tt> concept is now provided by the random number
37906 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
37907 and the placeholder should be removed.
37912 2009-05-02 Daniel adds:
37918 this issue completes adding necessary requirement to the
37919 third new <tt>random_shuffle</tt> overload. The current suggestion is:
37922 <blockquote><pre>template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
37923 requires ShuffleIterator<Iter>
37924 void random_shuffle(Iter first, Iter last, Rand&& g);
37925 </pre></blockquote>
37928 IMO this is still insufficient and I suggest to add the requirement
37930 <blockquote><pre>Convertible<Rand::result_type, Iter::difference_type>
37931 </pre></blockquote>
37933 to the list (as the two other overloads already have).
37942 Its true that this third overload is somewhat different from the remaining
37943 two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
37944 it's <tt>result_type</tt> is an integral type and that it satisfies
37945 <tt>UnsignedIntegralLike<result_type></tt>.
37948 To realize it's designated task, the algorithm has to invoke the
37949 <tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
37950 it's <tt>min()/max()</tt> limits to compute another index value that
37951 at this point is converted into <tt>Iter::difference_type</tt>. This is so,
37952 because 24.2.7 [random.access.iterators] uses this type as argument
37953 of it's algebraic operators. Alternatively consider the equivalent
37954 iterator algorithms in 24.4.4 [iterator.operations] with the same result.
37957 This argument leads us to the conclusion that we also need
37958 <tt>Convertible<Rand::result_type, Iter::difference_type></tt> here.
37970 Alisdair notes that point (ii) has already been addressed.
37973 We agree with the proposed resolution to point (i)
37974 with Daniel's added requirement.
37982 2009-06-05 Daniel updated proposed wording as recommended in Batavia.
37987 2009-07-28 Alisdair adds:
37992 Revert to Open, with a note there is consensus on direction but the
37993 wording needs updating to reflect removal of concepts.
37997 2009-10 post-Santa Cruz:
38002 Leave Open, Walter to work on it.
38006 2010 Pittsburgh: Moved to NAD Editorial, solved by
38007 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3056.pdf">N3056</a>.
38013 <p><b>Rationale:</b></p>
38016 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3056.pdf">N3056</a>.
38020 <p><b>Proposed resolution:</b></p>
38022 Change in [algorithms.syn] and 25.3.12 [alg.random.shuffle]:
38025 <blockquote><pre><del>concept UniformRandomNumberGenerator<typename Rand> { }</del>
38026 template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
38027 <ins>requires ShuffleIterator<Iter> &&
38028 Convertible<Rand::result_type, Iter::difference_type></ins>
38029 void random_shuffle(Iter first, Iter last, Rand&& g);
38030 </pre></blockquote>
38038 <h3><a name="1096"></a>1096. unconstrained rvalue ref parameters</h3>
38039 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
38040 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2010-10-23</p>
38041 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
38042 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
38043 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
38044 <p><b>Discussion:</b></p>
38046 TODO: Look at all cases of unconstrained rvalue ref parameters and check
38047 that concept req'ts work when <tt>T</tt> deduced as reference.
38051 We found some instances where that was not done correctly and we figure
38052 the possibility of deducing <tt>T</tt> to be an lvalue reference was probably
38053 overlooked elsewhere.
38061 Move to Open, pending proposed wording from Dave for further review.
38065 <p><b>Proposed resolution:</b></p>
38074 <h3><a name="1099"></a>1099. Various issues</h3>
38075 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
38076 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2010-10-23</p>
38077 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
38078 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
38079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
38080 <p><b>Discussion:</b></p>
38086 [2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
38087 MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple
38096 <blockquote><pre>template <MoveConstructible T1, MoveConstructible T2>
38097 pair<V1, V2> make_pair(T1&&, T2&&);
38098 </pre></blockquote>
38101 Actually I'm guessing we need something like <tt>MoveConstructible<V1,T1></tt>,
38102 i.e. "<tt>V1</tt> can be constructed from an rvalue of type <tt>T1</tt>."
38106 Ditto for <tt>make_tuple</tt>
38111 [2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
38112 talk about "copiable from generalized rvalue ref argument" for cases
38113 where we're going to forward and copy.
38117 This issue may well be quite large. Language in para 4 about "if
38118 an lvalue" is wrong because types aren't expressions.
38123 Maybe we should define the term "move" so we can just say in the
38124 effects, "<tt>f</tt> is moved into the newly-created thread" or something, and
38125 agree (and ideally document) that saying "<tt>f</tt> is moved" implies
38128 <blockquote><pre>F x(move(f))
38129 </pre></blockquote>
38132 is required to work. That would cover both ctors at once.
38137 p1199, call_once has all the same issues.
38141 [2009-03-21 Sat] p869 InputIterator pointer type should not be required
38142 to be convertible to const value_type*, rather it needs to have a
38143 operator-> of its own that can be used for the value type.
38147 This one is serious and unrelated to the move issue.
38151 [2009-03-21 Sat] p818 stack has the same problem with default ctor.
38154 [2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
38156 <blockquote><pre> requires MoveConstructible<Cont>
38157 explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont());
38160 Don't require MoveConstructible when default constructing Cont.
38161 Also missing semantics for move ctor.
38165 [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
38166 opposed to MoveConstructible?
38169 [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
38170 be MoveConstructible). No documented semantics for move c'tor. Or
38171 *any* of its 7 ctors!
38174 [2009-03-21 Sat] std::array should have constructors for C++0x,
38175 consequently must consider move construction.
38179 2009-05-01 Daniel adds:
38184 This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, which already handles
38185 deviation of <tt>std::array</tt> from container tables.
38189 [2009-03-21 Sat] p622 all messed up.
38193 para 8 "implementation-defined" is the wrong term; should be "see
38194 below" or something.
38197 para 12 "will be selected" doesn't make any sense because we're not
38198 talking about actual arg types.
38201 paras 9-13 need to be totally rewritten for concepts.
38206 [2009-03-21 Sat] Null pointer comparisons (p587) have all become
38207 unconstrained. Need to fix that
38210 [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
38211 We think CopyConstructible is the right reqt.
38214 make_pair needs Constructible<V1, T1&&> requirements!
38217 make_tuple needs something similar
38220 tuple bug in synopsis:
38222 <blockquote><pre> template <class... UTypes>
38223 requires Constructible<Types, const UTypes&>...
38224 template <class... UTypes>
38225 requires Constructible<Types, RvalueOf<UTypes>::type>...
38228 Note: removal of MoveConstructible requirements in std::function makes
38229 these routines unconstrained!
38234 2009-05-02 Daniel adds:
38239 This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>.
38243 these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
38245 <blockquote><pre> unique_ptr(pointer p, implementation-defined d);
38246 unique_ptr(pointer p, implementation-defined d);
38247 </pre></blockquote>
38249 multimap range constructor should not have MoveConstructible<value_type> requirement.
38252 same with insert(..., P&&); multiset has the same issue, as do
38253 unordered_multiset and unordered_multimap. Review these!
38263 Move to Open, pending proposed wording from Dave for further review.
38267 2009-10 post-Santa Cruz:
38272 Tentatively NAD. We are not sure what has been addressed and what hasn't.
38273 Recommend closing unless someone sorts this out into something more readable.
38278 <p><b>Rationale:</b></p>
38280 The issue(s) at hand not adequately communicated.
38284 <p><b>Proposed resolution:</b></p>
38293 <h3><a name="1101"></a>1101. <tt>unique</tt> requirements</h3>
38294 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
38295 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
38296 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
38297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
38298 <p><b>Discussion:</b></p>
38300 From Message c++std-core-14160 Howard wrote:
38304 It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:
38305 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1860.html#25.2.9%20-%20Unique">N1860</a>.
38313 That was overridden by the subsequent changes made for concepts in
38314 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2573.pdf">N2573</a>,
38315 which reimposed the C++03 requirements.
38319 My impression is that this overwrite was a simple (unintentional) mistake.
38320 Wording below to correct it.
38329 Howard notes this issue resolves a discrepancy between the synopsis
38330 and the description.
38333 Move to NAD Editorial.
38338 <p><b>Proposed resolution:</b></p>
38340 Change 25.3.9 [alg.unique]:
38343 <blockquote><pre>template<ForwardIterator Iter>
38344 requires OutputIterator<Iter, <ins>RvalueOf<</ins>Iter::reference<ins>>::type</ins>>
38345 && EqualityComparable<Iter::value_type>
38346 Iter unique(Iter first, Iter last);
38348 template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
38349 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
38350 && CopyConstructible<Pred>
38351 Iter unique(Iter first, Iter last, Pred pred);
38352 </pre></blockquote>
38355 Note that the synopsis in [algorithms.syn] is already correct.
38364 <h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
38365 <p><b>Section:</b> 23.4.1.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
38366 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-04-20 <b>Last modified:</b> 2010-10-23</p>
38367 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
38368 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
38369 <p><b>Discussion:</b></p>
38371 I have the impression that even the wording of current draft
38372 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
38373 does insufficiently express the intent of <tt>vector</tt>'s
38374 reallocation strategy. This has produced not too old library
38375 implementations which release memory in the <tt>clear()</tt> function
38376 and even modern articles about C++ programming cultivate
38377 the belief that <tt>clear</tt> is allowed to do exactly this. A typical
38378 example is something like this:
38381 <blockquote><pre>const int buf_size = ...;
38382 std::vector<T> buf(buf_size);
38383 for (int i = 0; i < some_condition; ++i) {
38384 buf.resize(buf_size);
38385 write_or_read_data(buf.data());
38386 buf.clear(); // Ensure that the next round get's 'zeroed' elements
38388 </pre></blockquote>
38390 where still the myth is ubiquitous that <tt>buf</tt> might be
38391 allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
38394 IMO the problem is due to the fact, that
38399 the actual memory-reallocation stability of <tt>std::vector</tt>
38400 is explained in 23.4.1.2 [vector.capacity]/3 and /6 which
38401 are describing just the effects of the <tt>reserve</tt>
38402 function, but in many examples (like above) there
38403 is no explicit call to <tt>reserve</tt> involved. Further-more
38404 23.4.1.2 [vector.capacity]/6 does only mention <em>insertions</em>
38405 and never mentions the consequences of erasing
38410 the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
38411 23.4.1.4 [vector.modifiers]/4 is silent about capacity changes. This
38412 easily causes a misunderstanding, because the counter
38413 parting insert functions described in 23.4.1.4 [vector.modifiers]/2
38414 explicitly say, that
38417 Causes reallocation if the new size is greater than the
38418 old capacity. If no reallocation happens, all the iterators
38419 and references before the insertion point remain valid.
38422 It requires a complex argumentation chain about four
38423 different places in the standard to provide the - possibly
38424 weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
38425 the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
38426 is the de-facto replacement of C99's dynamic arrays this
38427 type is near to a built-in type and it's specification should
38428 be clear enough that usual programmers can trust their
38440 Bill believes paragraph 1 of the proposed resolution is unnecessary
38441 because it is already implied (even if tortuously) by the current wording.
38449 2009-10 Santa Cruz:
38454 Mark as NAD. Rationale: there is no consensus to clarify the standard,
38455 general consensus that the standard is correct as written.
38460 <p><b>Proposed resolution:</b></p>
38462 This is a minimum version. I also
38463 suggest that the wording explaining the allocation strategy
38464 of <tt>std::vector</tt> in 23.4.1.2 [vector.capacity]/3 and /6 is moved into
38465 a separate sub paragraph of 23.4.1.2 [vector.capacity] <em>before</em>
38466 any of the prototype's are discussed, but I cannot provide
38467 reasonable wording changes now
38474 Change 23.4.1.2 [vector.capacity]/6 as follows:
38477 It is guaranteed that no reallocation takes place during
38478 insertions <ins>or erasures</ins> that happen after a call
38479 to <tt>reserve()</tt> until the time when an insertion would make
38480 the size of the vector greater than the value of <tt>capacity()</tt>.
38485 Change 23.4.1.4 [vector.modifiers]/4 as follows:
38488 <i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
38490 Invalidates iterators and references at or after the point
38501 <h3><a name="1105"></a>1105. Shouldn't <tt>Range</tt> be an <tt>auto concept</tt></h3>
38502 <p><b>Section:</b> X [iterator.concepts.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
38503 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-04-23 <b>Last modified:</b> 2010-10-23</p>
38504 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
38505 <p><b>Discussion:</b></p>
38508 2009-04-26 Herb adds:
38514 Here's a common example: We have many ISV customers who have built lots of
38515 in-house STL-like containers. Imagine that, for the past ten years, the user
38516 has been happily using his <tt>XYZCorpContainer<T></tt> that has <tt>begin()</tt> and <tt>end()</tt>
38517 and an iterator typedef, and indeed satisfies nearly all of <tt>Container</tt>,
38518 though maybe not quite all just like <tt>valarray</tt>. The user upgrades to a
38519 range-enabled version of a library, and now <tt>lib_algo( xyz.begin(), xyz.end());</tt>
38520 no longer works -- compiler error.
38523 Even though <tt>XYZCorpContainer</tt> matches the pre-conceptized version of the
38524 algorithm, and has been working for years, it appears the user has to write
38527 <blockquote><pre>template<class T> concept_map Range<XYZCorpContainer<T>> {};
38529 template<class T> concept_map Range<const XYZCorpContainer<T>> {};
38530 </pre></blockquote>
38535 But he may actually have to write this as we do for initializer list:
38537 <blockquote><pre>template<class T>
38538 concept_map Range<XYZCorpContainer<T>> {
38539 typedef T* iterator;
38540 iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
38541 iterator end(XYZCorpContainer<T> c) { return c.end(); }
38544 template<class T>
38545 concept_map Range<const XYZCorpContainer<T>> {
38546 typedef T* iterator;
38547 iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
38548 iterator end(XYZCorpContainer<T> c) { return c.end(); }
38550 </pre></blockquote>
38555 2009-04-28 Alisdair adds:
38561 I recommend NAD, although remain concerned about header organisation.
38564 A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
38565 There is a concept_map for all <tt>MemberContainers</tt> to <tt>Container</tt>, and then a
38566 further concept_map for all <tt>Container</tt> to <tt>Range</tt>, so the stated problem is not
38567 actually true. User defined containers will automatically match the <tt>Range</tt>
38568 concept without explicitly declaring a concept_map.
38571 The problem is that they should now provide an additional two headers,
38572 <tt><iterator_concepts></tt> and <tt><container_concepts></tt>.
38573 The only difference from
38574 making <tt>Range</tt> an auto concept would be this reduces to a single header,
38575 <tt><iterator_concepts></tt>.
38578 I am strongly in favour of any resolution that tackles the issue of
38579 explicitly requiring concept headers to make these concept maps available.
38589 We observe there is a recent paper by Bjarne that overlaps this issue.
38592 Alisdair continues to recommend NAD.
38595 Move to Open, and recommend the issue be deferred until after the next
38596 Committee Draft is issued.
38601 <p><b>Proposed resolution:</b></p>
38608 <h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
38609 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
38610 <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
38611 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
38612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
38613 <p><b>Discussion:</b></p>
38615 It is not clear, if multiple threads are waiting in a
38616 <tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
38622 <i>Throws:</i> the stored exception, if an exception was stored and not
38626 The "not retrieved before" suggests that only one exception is thrown,
38627 but one exception for each call to <tt>get()</tt> is needed, and multiple calls
38628 to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed.
38631 I suggest removing "and not retrieved before" from the Throws paragraph.
38632 I recommend adding a note that explains that multiple calls on <tt>get()</tt> are
38633 allowed, and each call would result in an exception if an exception was
38643 We note there is a pending paper by Detlef
38644 on such <tt>future</tt>-related issues;
38645 we would like to wait for his paper before proceeding.
38648 Alisdair suggests we may want language to clarify that this
38649 <tt>get()</tt> function can be called from several threads
38650 with no need for explicit locking.
38658 2010-01-23 Moved to Tentatively NAD Editorial after 5 positive votes on
38665 <p><b>Rationale:</b></p>
38668 <a href="file:///Users/hinnant/std%20documents/C++Mailings/papers/2009/n2997.htm">N2997</a>.
38672 <p><b>Proposed resolution:</b></p>
38674 Change 30.6.7 [futures.shared_future]:
38677 <blockquote><pre>const R& shared_future::get() const;
38678 R& shared_future<R&>::get() const;
38679 void shared_future<void>::get() const;
38684 -9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
38686 [<i>Note:</i> Multiple calls on <tt>get()</tt> are
38687 allowed, and each call would result in an exception if an exception was
38688 stored.
\97 <i>end note</i>]
38700 <h3><a name="1107"></a>1107. constructor <tt>shared_future(unique_future)</tt> by value?</h3>
38701 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
38702 <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
38703 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
38704 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
38705 <p><b>Discussion:</b></p>
38707 In the <tt>shared_future</tt> class definition in 30.6.7 [futures.shared_future]
38708 the move constructor
38709 that constructs a <tt>shared_future</tt> from an <tt>unique_future</tt> receives the
38710 parameter by value. In paragraph 3, the same constructor receives it as
38715 I think that is a mistake and the constructor should take a r-value
38719 <blockquote><pre>shared_future(unique_future<R>&& rhs);
38720 </pre></blockquote>
38728 We agree with the proposed resolution.
38731 Move to Tentatively Ready.
38736 2009-07-05 Daniel notes:
38741 The proposed change has already been incorported into the current working draft
38742 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
38746 <p><b>Proposed resolution:</b></p>
38748 Change the synopsis in 30.6.7 [futures.shared_future]:
38751 <blockquote><pre>shared_future(unique_future<R><ins>&&</ins> rhs);
38752 </pre></blockquote>
38755 Change the definition of the constructor in 30.6.7 [futures.shared_future]:
38758 <blockquote><pre>shared_future(<del>const</del> unique_future<R><ins>&&</ins> rhs);
38759 </pre></blockquote>
38767 <h3><a name="1109"></a>1109. <tt>std::includes</tt> should require <tt>CopyConstructible</tt> predicate</h3>
38768 <p><b>Section:</b> 25.4.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
38769 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-28 <b>Last modified:</b> 2010-10-23</p>
38770 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
38771 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
38772 <p><b>Discussion:</b></p>
38774 All the set operation algorithms require a <tt>CopyConstructible</tt> predicate, with
38775 the exception of <tt>std::includes</tt>. This looks like a typo as much as anything,
38776 given the general library requirement that predicates are copy
38777 constructible, and wording style of other set-like operations.
38785 We agree with the proposed resolution.
38786 Move to NAD Editorial.
38790 <p><b>Proposed resolution:</b></p>
38792 Change [algorithms.syn] and 25.4.5.1 [includes]:
38795 <blockquote><pre>template<InputIterator Iter1, InputIterator Iter2,
38796 <del>typename</del> <ins>CopyConstructible</ins> Compare>
38797 requires Predicate<Compare, Iter1::value_type, Iter2::value_type>
38798 && Predicate<Compare, Iter2::value_type, Iter1::value_type>
38799 bool includes(Iter1 first1, Iter1 last1,
38800 Iter2 first2, Iter2 last2,
38802 </pre></blockquote>
38809 <h3><a name="1111"></a>1111. associative containers underconstrained</h3>
38810 <p><b>Section:</b> 23.6 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
38811 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2010-10-23</p>
38812 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
38813 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
38814 <p><b>Discussion:</b></p>
38816 According to table 87 (n2857) the expression <tt>X::key_equal</tt> for an unordered
38817 container shall return a value of type <tt>Pred</tt>, where <tt>Pred</tt> is an equivalence
38822 However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>,
38823 and not <tt>EquivalenceRelation</tt>.
38832 We agree with the proposed resolution.
38840 <p><b>Proposed resolution:</b></p>
38842 For ordered containers, replace
38844 <blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
38845 </pre></blockquote>
38849 <blockquote><pre>StrictWeakOrder<auto, Key, Key> Compare = less<Key>
38850 </pre></blockquote>
38853 For unordered containers, replace
38855 <blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
38856 </pre></blockquote>
38860 <blockquote><pre>EquivalenceRelation<auto, Key, Key> Compare = less<Key>
38861 </pre></blockquote>
38863 As in the following declarations:
38868 Associative containers 23.6 [associative]
38871 1 Headers <map> and <set>:
38874 Header <map> synopsis
38876 <blockquote><pre> namespace std {
38877 template <ValueType Key, ValueType T,
38878 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38879 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
38880 requires NothrowDestructible<Key> && NothrowDestructible<T>
38881 && CopyConstructible<Compare>
38882 && AllocatableElement<Alloc, Compare, const Compare&>
38883 && AllocatableElement<Alloc, Compare, Compare&&>
38888 template <ValueType Key, ValueType T,
38889 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38890 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
38891 requires NothrowDestructible<Key> && NothrowDestructible<T>
38892 && CopyConstructible<Compare>
38893 && AllocatableElement<Alloc, Compare, const Compare&>
38894 && AllocatableElement<Alloc, Compare, Compare&&>
38900 </pre></blockquote>
38903 Header <set> synopsis
38905 <blockquote><pre> namespace std {
38906 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38907 Allocator Alloc = allocator<Key> >
38908 requires NothrowDestructible<Key> && CopyConstructible<Compare>
38909 && AllocatableElement<Alloc, Compare, const Compare&>
38910 && AllocatableElement<Alloc, Compare, Compare&&>
38915 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38916 Allocator Alloc = allocator<Key> >
38917 requires NothrowDestructible<Key> && CopyConstructible<Compare>
38918 && AllocatableElement<Alloc, Compare, const Compare&>
38919 && AllocatableElement<Alloc, Compare, Compare&&>
38925 </pre></blockquote>
38928 23.4.1p2 Class template map [map]
38930 <blockquote><pre> namespace std {
38931 template <ValueType Key, ValueType T,
38932 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38933 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
38934 requires NothrowDestructible<Key> && NothrowDestructible<T>
38935 && CopyConstructible<Compare>
38936 && AllocatableElement<Alloc, Compare, const Compare&>
38937 && AllocatableElement<Alloc, Compare, Compare&&>
38942 </pre></blockquote>
38946 23.4.2p2 Class template multimap [multimap]
38948 <blockquote><pre> namespace std {
38949 template <ValueType Key, ValueType T,
38950 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38951 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
38952 requires NothrowDestructible<Key> && NothrowDestructible<T>
38953 && CopyConstructible<Compare>
38954 && AllocatableElement<Alloc, Compare, const Compare&>
38955 && AllocatableElement<Alloc, Compare, Compare&&>
38960 </pre></blockquote>
38964 23.4.3p2 Class template set [set]
38966 <blockquote><pre> namespace std {
38967 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38968 Allocator Alloc = allocator<Key> >
38969 requires NothrowDestructible<Key> && CopyConstructible<Compare>
38970 && AllocatableElement<Alloc, Compare, const Compare&>
38971 && AllocatableElement<Alloc, Compare, Compare&&>
38976 </pre></blockquote>
38980 23.4.4p2 Class template multiset [multiset]
38982 <blockquote><pre> namespace std {
38983 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
38984 Allocator Alloc = allocator<Key> >
38985 requires NothrowDestructible<Key> && CopyConstructible<Compare>
38986 && AllocatableElement<Alloc, Compare, const Compare&>
38987 && AllocatableElement<Alloc, Compare, Compare&&>
38992 </pre></blockquote>
38995 23.5 Unordered associative containers [unord]
38998 1 Headers <unordered_map> and <unordered_set>:
39001 Header <unordered_map> synopsis
39003 <blockquote><pre> namespace std {
39004 // 23.5.1, class template unordered_map:
39005 template <ValueType Key,
39007 Callable<auto, const Key&> Hash = hash<Key>,
39008 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
39009 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
39010 requires NothrowDestructible<Key> && NothrowDestructible<T>
39011 && SameType<Hash::result_type, size_t>
39012 && CopyConstructible<Hash> && CopyConstructible<Pred>
39013 && AllocatableElement<Alloc, Pred, const Pred&>
39014 && AllocatableElement<Alloc, Pred, Pred&&>
39015 && AllocatableElement<Alloc, Hash, const Hash&>
39016 && AllocatableElement<Alloc, Hash, Hash&&>
39017 class unordered_map;
39019 // 23.5.2, class template unordered_multimap:
39020 template <ValueType Key,
39022 Callable<auto, const Key&> Hash = hash<Key>,
39023 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
39024 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
39025 requires NothrowDestructible<Key> && NothrowDestructible<T>
39026 && SameType<Hash::result_type, size_t>
39027 && CopyConstructible<Hash> && CopyConstructible<Pred>
39028 && AllocatableElement<Alloc, Pred, const Pred&>
39029 && AllocatableElement<Alloc, Pred, Pred&&>
39030 && AllocatableElement<Alloc, Hash, const Hash&>
39031 && AllocatableElement<Alloc, Hash, Hash&&>
39032 class unordered_multimap;
39036 </pre></blockquote>
39039 Header <unordered_set> synopsis
39041 <blockquote><pre> namespace std {
39042 // 23.5.3, class template unordered_set:
39043 template <ValueType Value,
39044 Callable<auto, const Value&> Hash = hash<Value>,
39045 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
39046 Allocator Alloc = allocator<Value> >
39047 requires NothrowDestructible<Value>
39048 && SameType<Hash::result_type, size_t>
39049 && CopyConstructible<Hash> && CopyConstructible<Pred>
39050 && AllocatableElement<Alloc, Pred, const Pred&>
39051 && AllocatableElement<Alloc, Pred, Pred&&>
39052 && AllocatableElement<Alloc, Hash, const Hash&>
39053 && AllocatableElement<Alloc, Hash, Hash&&>
39054 class unordered_set;
39056 // 23.5.4, class template unordered_multiset:
39057 template <ValueType Value,
39058 Callable<auto, const Value&> Hash = hash<Value>,
39059 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
39060 Allocator Alloc = allocator<Value> >
39061 requires NothrowDestructible<Value>
39062 && SameType<Hash::result_type, size_t>
39063 && CopyConstructible<Hash> && CopyConstructible<Pred>
39064 && AllocatableElement<Alloc, Pred, const Pred&>
39065 && AllocatableElement<Alloc, Pred, Pred&&>
39066 && AllocatableElement<Alloc, Hash, const Hash&>
39067 && AllocatableElement<Alloc, Hash, Hash&&>
39068 class unordered_multiset;
39072 </pre></blockquote>
39075 23.5.1p3 Class template unordered_map [unord.map]
39077 <blockquote><pre> namespace std {
39078 template <ValueType Key,
39080 Callable<auto, const Key&> Hash = hash<Key>,
39081 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
39082 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
39083 requires NothrowDestructible<Key> && NothrowDestructible<T>
39084 && SameType<Hash::result_type, size_t>
39085 && CopyConstructible<Hash> && CopyConstructible<Pred>
39086 && AllocatableElement<Alloc, Pred, const Pred&>
39087 && AllocatableElement<Alloc, Pred, Pred&&>
39088 && AllocatableElement<Alloc, Hash, const Hash&>
39089 && AllocatableElement<Alloc, Hash, Hash&&>
39090 class unordered_map
39095 </pre></blockquote>
39098 23.5.2p3 Class template unordered_multimap [unord.multimap]
39100 <blockquote><pre> namespace std {
39101 template <ValueType Key,
39103 Callable<auto, const Key&> Hash = hash<Key>,
39104 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
39105 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
39106 requires NothrowDestructible<Key> && NothrowDestructible<T>
39107 && SameType<Hash::result_type, size_t>
39108 && CopyConstructible<Hash> && CopyConstructible<Pred>
39109 && AllocatableElement<Alloc, Pred, const Pred&>
39110 && AllocatableElement<Alloc, Pred, Pred&&>
39111 && AllocatableElement<Alloc, Hash, const Hash&>
39112 && AllocatableElement<Alloc, Hash, Hash&&>
39113 class unordered_multimap
39118 </pre></blockquote>
39121 23.5.3p3 Class template unordered_set [unord.set]
39123 <blockquote><pre> namespace std {
39124 template <ValueType Value,
39125 Callable<auto, const Value&> Hash = hash<Value>,
39126 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
39127 Allocator Alloc = allocator<Value> >
39128 requires NothrowDestructible<Value>
39129 && SameType<Hash::result_type, size_t>
39130 && CopyConstructible<Hash> && CopyConstructible<Pred>
39131 && AllocatableElement<Alloc, Pred, const Pred&>
39132 && AllocatableElement<Alloc, Pred, Pred&&>
39133 && AllocatableElement<Alloc, Hash, const Hash&>
39134 && AllocatableElement<Alloc, Hash, Hash&&>
39135 class unordered_set
39140 </pre></blockquote>
39142 23.5.4p3 Class template unordered_multiset [unord.multiset]
39144 <blockquote><pre> namespace std {
39145 template <ValueType Value,
39146 Callable<auto, const Value&> Hash = hash<Value>,
39147 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
39148 Allocator Alloc = allocator<Value> >
39149 requires NothrowDestructible<Value>
39150 && SameType<Hash::result_type, size_t>
39151 && CopyConstructible<Hash> && CopyConstructible<Pred>
39152 && AllocatableElement<Alloc, Pred, const Pred&>
39153 && AllocatableElement<Alloc, Pred, Pred&&>
39154 && AllocatableElement<Alloc, Hash, const Hash&>
39155 && AllocatableElement<Alloc, Hash, Hash&&>
39156 class unordered_multiset
39161 </pre></blockquote>
39171 <h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
39172 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
39173 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06 <b>Last modified:</b> 2010-10-23</p>
39174 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
39175 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
39176 <p><b>Discussion:</b></p>
39178 <tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
39179 not model the Range concept so cannot be used with the new for-loop syntax.
39180 It is the only such type in the library that does NOT support the new for
39184 The obvious reason is that bitset does not support iterators.
39187 At least two reasonable solutions are available:
39191 Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
39192 of <tt>std::array</tt>
39195 Provide an unspecified concept_map for <tt>Range<bitset></tt>.
39199 The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
39200 but gives implementers greater freedom on the details. E.g. begin/end return
39201 some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
39202 increments its index on <tt>operator++</tt>. A vendor can settle for <tt>InputIterator</tt>
39203 support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
39206 I have a mild preference for option (ii) as I think it is less work to
39207 specify at this stage of the process, although (i) is probably more useful
39211 Hmm, my wording looks a little woolly, as it does not say what the element
39212 type of the range is. Do I get a range of <tt>bool</tt>, <tt>bitset<N>::reference</tt>, or
39213 something else entirely?
39216 I guess most users will assume the behaviour of reference, but expect to
39217 work with <tt>bool</tt>. <tt>Bool</tt> is OK for read-only traversal, but you really need to
39218 take a reference to a <tt>bitset::reference</tt> if you want to write back.
39227 We further recommend this be deferred until after the next Committee Draft.
39231 2009-05-25 Alisdair adds:
39237 I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
39238 probably set the precedent on how to write the wording.
39242 Howard: I've replaced the proposed wording with Alisdair's suggestion.
39249 2009-07-24 Daniel modifies the proposed wording for non-concepts.
39254 2009-10 post-Santa Cruz:
39259 Mark as Tentatively NAD Future due to the loss of concepts.
39264 <p><b>Rationale:</b></p>
39266 All concepts-related text has been removed from the draft.
39270 <p><b>Proposed resolution:</b></p>
39274 Modify the section 20.5 [template.bitset] <tt><bitset></tt> synopsis by adding
39275 the following at the end of the synopsis:
39277 <blockquote><pre><ins>
39278 // XX.X.X bitset range access [bitset.range]
39279 template<size_t N> <i>unspecified-1</i> begin(bitset<N>&);
39280 template<size_t N> <i>unspecified-2</i> begin(const bitset<N>&);
39281 template<size_t N> <i>unspecified-1</i> end(bitset<N>&);
39282 template<size_t N> <i>unspecified-2</i> end(const bitset<N>&);
39284 </pre></blockquote>
39288 Add a new section <ins>"bitset range access" [bitset.range]</ins>
39289 after the current section 20.5.4 [bitset.operators] with the following series of
39295 1. In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified-1</i>
39296 is a type that meets the requirements of a mutable random access
39297 iterator (24.2.7 [random.access.iterators]) whose <tt>value_type</tt> is <tt>bool</tt> and
39298 whose reference type is <tt>bitset<N>::reference</tt>.
39299 <i>unspecified-2</i> is a type that meets the requirements of a constant
39300 random access iterator (24.2.7 [random.access.iterators]) whose <tt>value_type</tt>
39301 is <tt>bool</tt> and whose reference type is <tt>bool</tt>.
39305 template<size_t N> <i>unspecified-1</i> begin(bitset<N>&);
39306 template<size_t N> <i>unspecified-2</i> begin(const bitset<N>&);
39310 <ins>2. Returns: an iterator referencing the first bit in the bitset.</ins>
39314 template<size_t N> <i>unspecified-1</i> end(bitset<N>&);
39315 template<size_t N> <i>unspecified-2</i> end(const bitset<N>&);
39319 <ins>3. Returns: an iterator referencing one past the last bit in the
39338 <h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
39339 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
39340 <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-10-23</p>
39341 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
39342 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
39343 <p><b>Discussion:</b></p>
39345 In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
39346 inherited from C library, <tt>va_copy</tt> seems to be missing. But in
39347 "Table 21 -- Header <tt><cstdarg></tt> synopsis" (18.10 [support.runtime]), there is.
39351 2009-10 post-Santa Cruz:
39356 Mark as Tentatively NAD Editorial, if Pete disagrees, Howard
39357 will move to Tentatively Ready
39362 <p><b>Proposed resolution:</b></p>
39364 Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
39372 <h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
39373 <p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
39374 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-10-23</p>
39375 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
39376 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
39377 <p><b>Discussion:</b></p>
39379 The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
39380 <tt>tuple_element</tt> do not support references-to-tuples. This can be
39381 annoying when a template deduced a parameter type to be a reference,
39382 which must be explicitly stripped with <tt>remove_reference</tt> before calling
39386 I am not proposing a resolution at this point, as there is a
39387 combinatorial explosion with lvalue/rvalue references and
39388 cv-qualification (see previous issue) that suggests some higher
39389 refactoring is in order. This might be something to kick back over to
39393 Note that we have the same problem in numeric_limits.
39397 2009-10 post-Santa Cruz:
39402 Move to Open. Alisdair to provide wording.
39412 Move to NAD. This is an extension after the FCD, without a clear motivation. May consider as NAD Future if motivating examples come forward.
39417 <p><b>Proposed resolution:</b></p>
39424 <h3><a name="1120"></a>1120. New type trait - remove_all</h3>
39425 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
39426 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-10-23</p>
39427 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
39428 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
39429 <p><b>Discussion:</b></p>
39431 Sometimes it is necessary to remove all qualifiers from a type before
39432 passing on to a further API. A good example would be calling the
39433 <tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
39434 with a deduced type inside a function template. If the deduced type is
39435 cv-qualified or a reference then the call will fail. The solution is to
39437 <tt>remove_cv<remove_reference<T>::type>::type</tt>, and
39438 note that the order matters.
39441 Suggest it would be helpful to add a new type trait,
39442 <tt>remove_all</tt>, that removes all top-level qualifiers from a type
39443 i.e. cv-qualification and any references. Define the term in such a way
39444 that if additional qualifiers are added to the language, then
39445 <tt>remove_all</tt> is defined as stripping those as well.
39449 2009-10-14 Daniel adds:
39454 <tt>remove_all</tt> seems too generic, a possible alternative matching
39455 the current naming style could be <tt>remove_cv_reference</tt> or
39456 <tt>remove_reference_cv</tt>. It should also be considered whether this
39457 trait should also remove 'extents', or pointer 'decorations'. Especially
39458 if the latter situations are considered as well, it might be easier to
39459 chose the name not in terms of what it <em>removes</em> (which might be
39460 a lot), but in terms of it <em>creates</em>. In this case I could think
39461 of e.g. <tt>extract_value_type</tt>.
39465 2009-10 Santa Cruz:
39475 <p><b>Proposed resolution:</b></p>
39482 <h3><a name="1121"></a>1121. Support for multiple arguments</h3>
39483 <p><b>Section:</b> 20.6.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
39484 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2010-10-23</p>
39485 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
39486 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
39487 <p><b>Discussion:</b></p>
39489 Both add and multiply could sensibly be called with more than two arguments.
39490 The variadic template facility makes such declarations simple, and is likely
39491 to be frequently wrapped by end users if we do not supply the variant
39495 We deliberately ignore divide at this point as it is not transitive.
39496 Likewise, subtract places special meaning on the first argument so I do not
39497 suggest extending that immediately. Both could be supported with analogous
39498 wording to that for add/multiply below.
39501 Note that the proposed resolution is potentially incompatible with that
39502 proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, although the addition of the typedef to ratio would be
39507 2009-10-30 Alisdair adds:
39513 The consensus of the group when we reviewed this in Santa Cruz was that
39514 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a> would proceed to Ready as planned, and the
39515 multi-paramater add/multiply templates should be renamed as
39516 <tt>ratio_sum</tt> and <tt>ratio_product</tt> to avoid the problem
39517 mixing template aliases with partial specializations.
39521 It was also suggested to close this issue as NAD Future as it does not
39522 correspond directly to any NB comment. NBs are free to submit a
39523 specific comment (and re-open) in CD2 though.
39527 Walter Brown also had concerns on better directing the order of
39528 evaluation to avoid overflows if we do proceed for 0x rather than TR1,
39529 so wording may not be complete yet.
39533 Alisdair updates wording.
39545 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
39550 <p><b>Rationale:</b></p>
39552 Does not have sufficient support at this time. May wish to reconsider for a
39557 <p><b>Proposed resolution:</b></p>
39560 Add the following type traits to p3 20.6 [ratio]
39563 <blockquote><pre>// ratio arithmetic
39564 template <class R1, class R2> struct ratio_add;
39565 template <class R1, class R2> struct ratio_subtract;
39566 template <class R1, class R2> struct ratio_multiply;
39567 template <class R1, class R2> struct ratio_divide;
39568 <ins>template <class R1, class ... RList> struct ratio_sum;</ins>
39569 <ins>template <class R1, class ... RList> struct ratio_product;</ins>
39570 </pre></blockquote>
39573 after 20.6.2 [ratio.arithmetic] p1: add
39576 <blockquote><pre>template <class R1, class ... RList> struct ratio_sum; // declared, never defined
39578 template <class R1> struct ratio_sum<R1> : R1 {};
39582 <i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
39585 <pre>template <class R1, class R2, class ... RList>
39586 struct ratio_sum<R1, R2, RList...>
39587 : ratio_add< R1, ratio_sum<R2, RList...>> {
39592 <i>Requires:</i> <tt>R1</tt> and each element in parmater pack
39593 <tt>RList</tt> is a specialization of class template <tt>ratio</tt>
39598 after 20.6.2 [ratio.arithmetic] p3: add
39601 <blockquote><pre>template <class R1, class ... RList> struct ratio_product; // declared, never defined
39603 template <class R1> struct ratio_product<R1> : R1 {};
39607 <i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
39610 <pre>template <class R1, class R2, class ... RList>
39611 struct ratio_sum<R1, R2, RList...>
39612 : ratio_add< R1, ratio_product<R2, RList...>> {
39617 <i>Requires:</i> <tt>R1</tt> and each element in parmater pack
39618 <tt>RList</tt> is a specialization of class template <tt>ratio</tt>
39630 <h3><a name="1124"></a>1124. Invalid definition of concept RvalueOf</h3>
39631 <p><b>Section:</b> X [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
39632 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
39633 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
39634 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
39635 <p><b>Discussion:</b></p>
39637 A recent news group
39638 <a href="http://groups.google.de/group/comp.std.c++/browse_frm/thread/8eb92768a19fb46f">article</a>
39639 points to several defects in the
39640 specification of reference-related concepts.
39643 One problem of the concept <tt>RvalueOf</tt> as currently defined in
39644 X [concept.transform]:
39647 <blockquote><pre>concept RvalueOf<typename T> {
39648 typename type = T&&;
39649 requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>;
39652 template<typename T> concept_map RvalueOf<T&> {
39653 typedef T&& type;
39655 </pre></blockquote>
39658 is that if <tt>T</tt> is an lvalue-reference, the requirement
39659 <tt>Convertible<T&&,type></tt> isn't satisfied for
39660 lvalue-references, because after reference-collapsing in the concept
39661 definition we have <tt>Convertible<T&,type></tt> in this case,
39662 which isn't satisfied in the concept map template and also is not the
39663 right constraint either. I think that the reporter is right that
39664 <tt>SameType</tt> requirements should do the job and that we also should
39665 use the new <tt>RvalueReference</tt> concept to specify a best matching
39670 <p><b>Proposed resolution:</b></p>
39672 In X [concept.transform] before p. 4 change as indicated:
39675 <blockquote><pre>auto concept RvalueOf<typename T> {
39676 <del>typename</del><ins>RvalueReference</ins> type = T&&;
39677 requires <del>ExplicitlyConvertible<T&, type> && Convertible<T&&, type></del><ins>SameType<T&, type&></ins>;
39679 </pre></blockquote>
39686 <h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
39687 <p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
39688 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
39689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
39690 <p><b>Discussion:</b></p>
39692 <tt>ostream_iterator</tt> has not been updated to support moveable types, in a
39693 similar manner to the insert iterators.
39694 Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
39695 restricted to dealing with do not support extra-efficient moving.
39699 2009-11-10 Howard adds:
39704 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale
39709 <p><b>Proposed resolution:</b></p>
39711 Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
39712 in 24.6.2 [ostream.iterator], para 2:
39715 <blockquote><pre>ostream_iterator<T,charT,traits>& operator=(const T& value);
39716 <ins>ostream_iterator<T,charT,traits>& operator=(T&& value);</ins>
39717 </pre></blockquote>
39720 Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
39724 <pre>ostream_iterator& operator=(T&& value);
39728 -2- <i>Effects:</i>
39730 <blockquote><pre>*out_stream << std::move(value);
39732 *out_stream << delim;
39734 </pre></blockquote>
39740 <p><b>Rationale:</b></p>
39742 Several objections to move forward with this issue were voiced in the thread
39743 starting with c++std-lib-25438. Among them is that we know of no motivating
39744 use case to make streaming rvalues behave differently than streaming const
39753 <h3><a name="1127"></a>1127. rvalue references and iterator traits</h3>
39754 <p><b>Section:</b> 24.4.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
39755 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
39756 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
39757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
39758 <p><b>Discussion:</b></p>
39760 The deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained)
39761 iterators features the (exposition only) concept:
39764 <blockquote><pre>concept IsReference<typename T> { } // exposition only
39765 template<typename T> concept_map IsReference<T&> { }
39766 </pre></blockquote>
39768 Now this looks exactly like the <tt>LvalueReference</tt> concept recently added to
39769 clause 20, so I wonder if we should use that instead?
39770 Then I consider the lack of rvalue-reference support, which means that
39771 <tt>move_iterator</tt> would always flag as merely supporting the <tt>input_iterator_tag</tt>
39772 category. This suggests we retain the exposition concept, but add a second
39773 concept_map to support rvalue references.
39776 I would suggest adding the extra concept_map is the right way forward, but
39777 still wonder if the two exposition-only concepts in this clause might be
39778 worth promoting to clause 20. That question might better be answered with a
39779 fuller investigation of type_trait/concept unification though.
39783 <p><b>Proposed resolution:</b></p>
39785 In Iterator traits 24.4.1 [iterator.traits] para 4 add:
39788 <blockquote><pre>concept IsReference<typename T> { } // exposition only
39789 template<typename T> concept_map IsReference<T&> { }
39790 <ins>template<typename T> concept_map IsReference<T&&> { }</ins>
39791 </pre></blockquote>
39799 <h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits<T*></tt></h3>
39800 <p><b>Section:</b> X [iterator.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
39801 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
39802 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
39803 <p><b>Discussion:</b></p>
39805 The <tt><iterator></tt> header synopsis declares a partial specialization of
39806 <tt>iterator_traits</tt> to support pointers, X [iterator.syn]. The implication
39807 is that specialization will be described in D10, yet it did not follow the
39808 rest of the deprecated material into this clause.
39811 However, this is not as bad as it first seems!
39812 There are partial specializations of <tt>iterator_traits</tt> for types that satisfy
39813 the various Iterator concepts, and there are concept_maps for pointers to
39814 explicitly support the <tt>RandomAccessIterator</tt> concept, so the required
39815 template will be present - just not in the manner advertised.
39818 I can see two obvious solutions:
39823 Restore the <tt>iterator_traits<T*></tt> partial specialization in D.10
39826 Remove the declaration of <tt>iterator_traits<T*></tt> from 24.3 synopsis
39830 I recommend option (ii) in the wording below
39833 Option (ii) could be extended to strike all the declarations of deprecated
39834 material from the synopsis, as it is effectively duplicating D.10 anyway.
39835 This is the approach taken for deprecated library components in the 98/03
39836 standards. This is probably a matter best left to the Editor though.
39840 <p><b>Proposed resolution:</b></p>
39842 In X [iterator.syn] strike:
39845 <blockquote><pre><del>template<class T> struct iterator_traits<T*>;</del>
39846 </pre></blockquote>
39854 <h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
39855 <p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
39856 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30 <b>Last modified:</b> 2010-10-23</p>
39857 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.cons">issues</a> in [istream.iterator.cons].</p>
39858 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
39859 <p><b>Discussion:</b></p>
39861 <tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
39862 values. The default constructor is frequently used to terminate ranges, and
39863 could easily be a literal value for <tt>istreambuf_iterator</tt>, and
39864 <tt>istream_iterator</tt> when iterating value types. A little more work using a
39865 suitably sized/aligned char-array for storage (or an updated component like
39866 <tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
39867 <tt>constexpr</tt> default constructor in all cases, although we might leave this
39868 tweak as a QoI issue. Note that requiring <tt>constexpr</tt> be supported also
39869 allows us to place no-throw guarantees on this constructor too.
39873 2009-06-02 Daniel adds:
39879 I agree with the usefulness of the issue suggestion, but we need
39880 to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
39881 Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
39882 a copy constructor and a destructor and explains their semantic in
39883 24.6.1.1 [istream.iterator.cons]/3+4.
39886 The prototype semantic specification is ok (although it seems
39887 somewhat redundant to me, because the semantic doesn't say
39888 anything interesting in both cases), but for support of trivial class
39889 types we also need a trivial copy constructor and destructor as of
39890 9 [class]/6. The current non-informative specification of these
39891 two special members suggests to remove their explicit declaration
39892 in the class and add explicit wording that says that if <tt>T</tt> is
39893 trivial a default constructed iterator is also literal, alternatively it
39894 would be possible to mark both as defaulted and add explicit
39895 (memberwise) wording that guarantees that they are trivial.
39898 Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
39899 ensure triviality are not sufficient as suggested, because the
39900 library does not yet give general guarantees that a defaulted
39901 special member declaration makes this member also trivial.
39902 Note that e.g. the atomic types do give a general statement!
39905 Finally there is a wording issue: There does not exist something
39906 like a "literal constructor". The core language uses the term
39907 "constexpr constructor" for this.
39915 Change 24.6.1 [istream.iterator]/3 as indicated:
39917 <blockquote><pre><ins>constexpr</ins> istream_iterator();
39918 istream_iterator(istream_type& s);
39919 istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
39920 ~istream_iterator()<ins> = default</ins>;
39921 </pre></blockquote>
39925 Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
39927 <blockquote><pre><ins>constexpr</ins> istream_iterator();
39930 -1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
39931 then this constructor shall be a constexpr constructor.</ins>
39937 Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
39939 <blockquote><pre>istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
39942 -3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
39943 this constructor shall be a trivial copy constructor.</ins>
39949 Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
39952 <blockquote><pre>~istream_iterator()<ins> = default</ins>;
39955 -4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
39956 this destructor shall be a trivial
39963 Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
39966 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
39967 <ins>istreambuf_iterator(const istreambuf_iterator&) throw() = default;</ins>
39968 <ins>~istreambuf_iterator() throw() = default;</ins>
39969 </pre></blockquote>
39973 Change 24.6.3 [istreambuf.iterator]/1 as indicated:
39976 [..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
39977 <tt>istreambuf_iterator(0)</tt> both
39978 construct an end of stream iterator object suitable for use as an
39979 end-of-range. <ins>All
39980 specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
39981 constructor, a constexpr default
39982 constructor and a trivial destructor.</ins>
39989 2009-10 Santa Cruz:
39994 NAD Editorial. Solved by
39995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
40000 <p><b>Proposed resolution:</b></p>
40002 24.6.1 [istream.iterator] para 3
40005 <blockquote><pre><ins>constexpr</ins> istream_iterator();
40006 </pre></blockquote>
40009 24.6.1.1 [istream.iterator.cons]
40012 <blockquote><pre><ins>constexpr</ins> istream_iterator();
40015 -1- <i>Effects:</i> Constructs the end-of-stream iterator.
40016 <ins>If <tt>T</tt> is a literal type, then this constructor shall
40017 be a literal constructor.</ins>
40022 24.6.3 [istreambuf.iterator]
40025 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
40026 </pre></blockquote>
40034 <h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
40035 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
40036 <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2010-10-23</p>
40037 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
40038 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
40039 <p><b>Discussion:</b></p>
40040 <p><b>Addresses JP 30</b></p>
40043 C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
40044 following codes show two types of tree structured exception handling.
40047 The first one is based on <tt>nested_exception</tt> in C++0x,
40048 while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
40049 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
40052 Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
40053 throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
40054 throws an exception.
40057 List A (code of tree structured exception handling based on nested_exception
40061 <blockquote><pre>void A()
40065 std::vector<exception_ptr> exception_list;
40068 // A_a() does a similar processing as A().
40073 exception_list.push_back(current_exception());
40076 // ***The processing A() has to do even when A_a() fails. ***
40079 // A_b() does a similar processing as A().
40084 exception_list.push_back(current_exception());
40086 if (!exception_list.empty())
40088 throw exception_list;
40093 throw_with_nested(A_exception("someone error"));
40096 void print_tree_exception(exception_ptr e, const std::string & indent ="")
40098 const char * indent_unit = " ";
40099 const char * mark = "- ";
40102 rethow_exception(e);
40104 catch(const std::vector<exception_ptr> e)
40106 for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i)
40108 print_tree_exception(i, indent);
40111 catch(const std::nested_exception e)
40113 print_tree_exception(evil_i(e), indent +indent_unit);
40115 catch(const std::exception e)
40117 std::cout << indent << mark << e.what() << std::endl;
40121 std::cout << indent << mark << "unknown exception" << std::endl;
40124 int main(int, char * [])
40132 print_tree_exception(current_exception());
40134 return EXIT_SUCCESS;
40136 </pre></blockquote>
40139 List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
40140 "trickerr.h" (in Japanese), refer to:
40141 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
40144 <blockquote><pre>void A()
40146 tricklib::error_listener_type error_listener;
40147 // A_a() is like A(). A_a() can throw tree structured exception.
40150 // *** It must do process so that A_a() throws exception in A(). ***
40151 // A_b() is like A(). A_b() can throw tree structured exception.
40154 if (error_listener.has_error()) // You can write this "if block" in destructor
40155 // of class derived from error_listener_type.
40157 throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
40160 void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "")
40162 const char * indent_unit = " ";
40163 const char * mark = "- ";
40165 tricklib::error_type error = a_error;
40168 std::cout << indent << mark << error->message << std::endl;
40169 if (error->children)
40171 print_tree_error(error->children, indent +indent_unit);
40173 error = error->next;
40176 int main(int, char * [])
40178 tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
40184 catch(error_type error)
40186 print_tree_error(error);
40190 std::cout << "- unknown exception" << std::endl;
40192 return EXIT_SUCCESS;
40194 </pre></blockquote>
40200 We will focus on the method A() since the other methods, also main(), occur
40201 only once respectively.
40206 In the List A above (of the nested exception handling), it is hard to
40207 find out an active reason to use the nested exception handling at this
40208 scene. Rather, we can take a simpler description by throwing the entire
40209 exception_list directly to the top level.
40212 The code in the same example gives us a kind of redundant impression,
40213 which might have come from the fact that the try-throw-catch framework does
40214 not assume a tree structured exception handling.
40219 According to the above observation, we cannot help concluding that it is not
40220 so easy to use the nested_exception handling as a tree structured exception
40221 handling mechanism in a practical sense.
40224 This text is based on the web page below (in Japanese).
40225 <a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
40229 2009-10 Santa Cruz:
40234 Mark as NAD. The committee agrees that nested_exception is not a good
40235 match for this usage model. The committee did not see a way of improving
40236 this within the timeframe allowed.
40241 <p><b>Proposed resolution:</b></p>
40250 <h3><a name="1139"></a>1139. Thread support library not concept enabled</h3>
40251 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
40252 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2010-10-23</p>
40253 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
40254 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
40255 <p><b>Discussion:</b></p>
40257 <p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p>
40260 The thread chapter is not concept enabled.
40265 <p><b>Proposed resolution:</b></p>
40272 <h3><a name="1140"></a>1140. Numerics library not concept enabled</h3>
40273 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
40274 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2010-10-23</p>
40275 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
40276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
40277 <p><b>Discussion:</b></p>
40279 <p><b>Addresses US 84</b></p>
40282 The numerics chapter is not concept enabled.
40286 The portion of this comment dealing with random numbers was resolved by
40287 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a>,
40288 which was accepted in Summit.
40293 <p><b>Proposed resolution:</b></p>
40300 <h3><a name="1141"></a>1141. Input/Output library not concept enabled</h3>
40301 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
40302 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2010-10-23</p>
40303 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
40304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
40305 <p><b>Discussion:</b></p>
40307 <p><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72, UK 308</b></p>
40310 The input/output chapter is not concept enabled.
40315 <p><b>Proposed resolution:</b></p>
40322 <h3><a name="1142"></a>1142. Regular expressions library not concept enabled</h3>
40323 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
40324 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2010-10-23</p>
40325 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
40326 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
40327 <p><b>Discussion:</b></p>
40329 <p><b>Addresses US 86, UK 309, UK 310</b></p>
40332 The regular expressions chapter is not concept enabled.
40337 <p><b>Proposed resolution:</b></p>
40344 <h3><a name="1143"></a>1143. Atomic operations library not concept enabled</h3>
40345 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
40346 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2010-10-23</p>
40347 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
40348 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
40349 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
40350 <p><b>Discussion:</b></p>
40352 <p><b>Addresses US 87, UK 311</b></p>
40355 The atomics chapter is not concept enabled.
40359 Needs to also consider issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>.
40363 2009-10 Santa Cruz:
40368 NAD Editorial. Solved by
40369 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40374 <p><b>Proposed resolution:</b></p>
40381 <h3><a name="1145"></a>1145. inappropriate headers for atomics</h3>
40382 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
40383 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16 <b>Last modified:</b> 2010-10-23</p>
40384 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
40385 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
40386 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
40387 <p><b>Discussion:</b></p>
40389 <p><b>Addresses UK 312</b></p>
40392 The contents of the <tt><stdatomic.h></tt> header are not listed anywhere,
40393 and <tt><cstdatomic></tt> is listed as a C99 header in chapter 17.
40394 If we intend to use these for compatibility with a future C standard,
40395 we should not use them now.
40399 2009-10 Santa Cruz:
40404 NAD Editorial. Solved by
40405 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40410 <p><b>Proposed resolution:</b></p>
40412 Remove <tt><cstdatomic></tt> from the C99 headers in table 14.
40413 Add a new header <tt><atomic></tt> to the headers in table 13.
40414 Update chapter 29 to remove reference to <tt><stdatomic.h></tt>
40415 and replace the use of <tt><cstdatomic></tt> with <tt><atomic></tt>.
40418 If and when WG14 adds atomic operations to C
40419 we can add corresponding headers to table 14 with a TR.
40428 <h3><a name="1146"></a>1146. "lockfree" does not say enough</h3>
40429 <p><b>Section:</b> 29.4 [atomics.lockfree] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
40430 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16 <b>Last modified:</b> 2010-10-23</p>
40431 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.lockfree">issues</a> in [atomics.lockfree].</p>
40432 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
40433 <p><b>Discussion:</b></p>
40435 <p><b>Addresses US 88</b></p>
40438 The "lockfree" facilities do not tell the programmer enough.
40442 There are 2 problems here.
40443 First, at least on x86,
40444 it's less important to me whether some integral types are lock free
40445 than what is the largest type I can pass to atomic and have it be lock-free.
40446 For example, if <tt>long long</tt>s are not lock-free,
40447 <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> is probably 1,
40448 but I'd still be interested in knowing whether longs are always lock-free.
40449 Or if long longs at any address are lock-free,
40450 I'd expect <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> to be 2,
40451 but I may actually care whether I have access to
40452 the <code>cmpxchg16b</code> instruction.
40453 None of the support here helps with that question.
40454 (There are really 2 related questions here:
40455 what alignment requirements are there for lock-free access;
40456 and what processor is the program actually running on,
40457 as opposed to what it was compiled for?)
40461 Second, having <tt>atomic_is_lock_free</tt> only apply to individual objects
40463 (except, as Lawrence Crowl points out,
40464 for throwing an exception when an object is unexpectedly not lock-free).
40465 I'm likely to want to use its result to decide what algorithm to use,
40466 and that algorithm is probably going to allocate new memory
40467 containing atomic objects and then try to act on them.
40468 If I can't predict the lock-freedom of the new object
40469 by checking the lock-freedom of an existing object,
40470 I may discover after starting the algorithm that I can't continue.
40474 2009-06-16 Jeffrey Yasskin adds:
40480 To solve the first problem, I think 2 macros would help:
40481 <tt>MAX_POSSIBLE_LOCK_FREE_SIZE</tt> and <tt>MAX_GUARANTEED_LOCK_FREE_SIZE</tt>,
40482 which expand to the maximum value of <tt>sizeof(T)</tt> for which atomic may
40483 (or will, respectively) use lock-free operations.
40484 Lawrence points out that this
40485 "relies heavily on implementations
40486 using word-size compare-swap on sub-word-size types,
40487 which in turn requires address modulation."
40488 He expects that to be the end state anyway, so it doesn't bother him much.
40492 To solve the second,
40493 I think one could specify that equally aligned objects of the same type
40494 will return the same value from <tt>atomic_is_lock_free()</tt>.
40495 I don't know how to specify "equal alignment".
40496 Lawrence suggests an additional function, <tt>atomic_is_always_lock_free()</tt>.
40501 2009-10-22 Benjamin Kosnik:
40507 In the evolution discussion of N2925, "More Collected Issues with
40508 Atomics," there is an action item with respect to
40509 LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, US 88
40513 This is stated in the paper as:
40516 Relatedly, Mike Sperts will create an issue to propose adding a traits
40517 mechanism to check the compile-time properties through a template
40518 mechanism rather than macros
40522 Here is my attempt to do this. I don't believe that a separate trait is
40523 necessary for this, and that instead <tt>atomic_integral::is_lock_free</tt> can
40524 be re-purposed with minimal work as follows.
40528 Howard: Put Benjamin's wording in the proposed wording section.
40535 2009-10-22 Alberto Ganesh Barbati:
40541 Just a thought... wouldn't it be better to use a scoped enum instead of
40542 plain integers? For example:
40545 <blockquote><pre>enum class is_lock_free
40547 never = 0, sometimes = 1, always = 2;
40549 </pre></blockquote>
40552 if compatibility with C is deemed important, we could use an unscoped
40553 enum with suitably chosen names. It would still be more descriptive
40560 2009-10 Santa Cruz:
40565 NAD Editorial. Solved by
40566 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40571 <p><b>Proposed resolution:</b></p>
40573 Header <tt><cstdatomic></tt> synopsis [atomics.synopsis]
40580 <blockquote><pre>namespace std {
40582 // 29.4, lock-free property
40583 <del>#define ATOMIC_INTEGRAL_LOCK_FREE unspecified</del>
40584 <ins>#define ATOMIC_CHAR_LOCK_FREE unspecified
40585 #define ATOMIC_CHAR16_T_LOCK_FREE unspecified
40586 #define ATOMIC_CHAR32_T_LOCK_FREE unspecified
40587 #define ATOMIC_WCHAR_T_LOCK_FREE unspecified
40588 #define ATOMIC_SHORT_LOCK_FREE unspecified
40589 #define ATOMIC_INT_LOCK_FREE unspecified
40590 #define ATOMIC_LONG_LOCK_FREE unspecified
40591 #define ATOMIC_LLONG_LOCK_FREE unspecified</ins>
40592 #define ATOMIC_ADDRESS_LOCK_FREE unspecified
40593 </pre></blockquote>
40596 Lock-free Property 29.4 [atomics.lockfree]
40600 Edit the synopsis as follows.
40603 <blockquote><pre>namespace std {
40604 <del>#define ATOMIC_INTEGRAL_LOCK_FREE unspecified</del>
40605 <ins>#define ATOMIC_CHAR_LOCK_FREE unspecified
40606 #define ATOMIC_CHAR16_T_LOCK_FREE unspecified
40607 #define ATOMIC_CHAR32_T_LOCK_FREE unspecified
40608 #define ATOMIC_WCHAR_T_LOCK_FREE unspecified
40609 #define ATOMIC_SHORT_LOCK_FREE unspecified
40610 #define ATOMIC_INT_LOCK_FREE unspecified
40611 #define ATOMIC_LONG_LOCK_FREE unspecified
40612 #define ATOMIC_LLONG_LOCK_FREE unspecified</ins>
40613 #define ATOMIC_ADDRESS_LOCK_FREE unspecified
40615 </pre></blockquote>
40618 Edit paragraph 1 as follows.
40622 The <ins>ATOMIC_...._LOCK_FREE</ins> macros <del>ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE</del> indicate the general lock-free
40623 property of <del>integral and address atomic</del> <ins>the corresponding atomic integral</ins> types<ins>, with the
40624 signed and unsigned variants grouped together</ins>.
40625 <del>The properties also apply to the corresponding specializations of the atomic template.</del>
40627 indicates that the types are never lock-free. A value of 1
40628 indicates that the types are sometimes lock-free. A value of 2
40629 indicates that the types are always lock-free.
40633 Operations on Atomic Types 29.6 [atomics.types.operations]
40640 <blockquote><pre><del>void</del> <ins>static constexpr bool</ins> A::is_lock_free() const volatile;
40643 <i>Returns:</i> True if the <del>object's</del> <ins>types's</ins> operations are lock-free, false
40646 [<i>Note:</i> In the same way that <tt><limits></tt>
40647 <tt>std::numeric_limits<short>::max()</tt> is related to
40648 <tt><limits.h></tt> <tt>__LONG_LONG_MAX__</tt>, <tt><atomic>
40649 std::atomic_short::is_lock_free</tt> is related to
40650 <tt><stdatomic.h></tt> and <tt>ATOMIC_SHORT_LOCK_FREE</tt>
\97
40662 <h3><a name="1147"></a>1147. non-volatile atomic functions</h3>
40663 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
40664 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16 <b>Last modified:</b> 2010-10-23</p>
40665 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
40666 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
40667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
40668 <p><b>Discussion:</b></p>
40670 <p><b>Addresses US 90</b></p>
40674 declares all of the functions dealing with atomics (section 29.6 [atomics.types.operations])
40675 to take volatile arguments.
40676 Yet it also says (29.4-3),
40681 [ Note: Many operations are volatile-qualified.
40682 The "volatile as device register" semantics have not changed in the standard.
40683 This qualification means that volatility is preserved
40684 when applying these operations to volatile objects.
40685 It does not mean that operations on non-volatile objects become volatile.
40686 Thus, volatile qualified operations on non-volatile objects
40687 may be merged under some conditions.
\97end note ]
40692 I was thinking about how to implement this in gcc,
40693 and I believe that we'll want to overload most of the functions
40694 on volatile and non-volatile.
40699 To let the compiler take advantage of the permission
40700 to merge non-volatile atomic operations and reorder atomics in certain,
40701 we'll need to tell the compiler backend
40702 about exactly which atomic operation was used.
40703 So I expect most of the functions of the form atomic_<op>_explicit()
40704 (e.g. atomic_load_explicit, atomic_exchange_explicit,
40705 atomic_fetch_add_explicit, etc.)
40706 to become compiler builtins.
40707 A builtin can tell whether its argument was volatile or not,
40708 so those functions don't really need extra explicit overloads.
40709 However, I don't expect that we'll want to add builtins
40710 for every function in chapter 29,
40711 since most can be implemented in terms of the _explicit free functions:
40714 <pre><code>class atomic_int {
40715 __atomic_int_storage value;
40717 int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
40718 // &value has type "volatile __atomic_int_storage*".
40719 atomic_fetch_add_explicit(&value, increment, order);
40726 But now this <em>always</em> calls
40727 the volatile builtin version of atomic_fetch_add_explicit(),
40728 even if the atomic_int wasn't declared volatile.
40729 To preserve volatility and the compiler's permission to optimize,
40733 <pre><code>class atomic_int {
40734 __atomic_int_storage value;
40736 int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
40737 atomic_fetch_add_explicit(&value, increment, order);
40739 int fetch_add(int increment, memory_order order = memory_order_seq_cst) {
40740 atomic_fetch_add_explicit(&value, increment, order);
40747 But this is visibly different from the declarations in the standard
40748 because it's now overloaded.
40749 (Consider passing &atomic_int::fetch_add as a template parameter.)
40753 The implementation may already have permission to add overloads
40754 to the member functions:
40759 17.6.4.5 [member.functions] An implementation may declare additional non-virtual
40760 member function signatures within a class:<br>
40764 <li>by adding a member function signature for a member function name.</li>
40769 but I don't see an equivalent permission to add overloads to the free functions.
40773 2009-06-16 Lawrence adds:
40779 I recommend allowing non-volatile overloads.
40784 2009-10 Santa Cruz:
40789 NAD Editorial. Solved by
40790 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40795 <p><b>Proposed resolution:</b></p>
40802 <h3><a name="1148"></a>1148. Wrong argument type of I/O stream manipulators <tt>setprecision()</tt>
40803 and <tt>setw()</tt></h3>
40804 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
40805 <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-20 <b>Last modified:</b> 2010-10-23</p>
40806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
40807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
40808 <p><b>Discussion:</b></p>
40810 The header <tt><iomanip></tt> synopsis in 27.7 [iostream.format] specifies
40812 <blockquote><pre>T5 setprecision(int n);
40814 </pre></blockquote>
40817 The argument types should be streamsize, as in class <tt>ios_base</tt>
40818 (see 27.5.2 [ios.base]):
40820 <blockquote><pre>streamsize precision() const;
40821 streamsize precision(streamsize prec);
40822 streamsize width() const;
40823 streamsize width(streamsize wide);
40824 </pre></blockquote>
40827 (Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
40831 2009-07-29 Daniel clarified wording.
40842 No concensus for this change. There was some interest in doing the opposite
40843 fix: Change the <tt>streamsize</tt> in <tt><ios></tt> to <tt>int</tt>.
40844 But ultimately there was no concensus for that change either.
40850 <p><b>Proposed resolution:</b></p>
40854 In 27.7 [iostream.format], header <tt><iomanip></tt> synopsis change as indicated:
40857 <blockquote><pre>T5 setprecision(<del>int</del><ins>streamsize</ins> n);
40858 T6 setw(<del>int</del><ins>streamsize</ins> n);
40859 </pre></blockquote>
40864 In 27.7.3 [std.manip], just before p. 6 change as indicated:
40867 <blockquote><pre>unspecified setprecision(<del>int</del><ins>streamsize</ins> n);
40868 </pre></blockquote>
40873 In 27.7.3 [std.manip], just before p. 7 change as indicated:
40876 <blockquote><pre>unspecified setw(<del>int</del><ins>streamsize</ins> n);
40877 </pre></blockquote>
40889 <h3><a name="1149"></a>1149. Reformulating NonemptyRange axiom</h3>
40890 <p><b>Section:</b> X [rand.concept.urng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
40891 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2009-06-25 <b>Last modified:</b> 2010-10-23</p>
40892 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
40893 <p><b>Discussion:</b></p>
40895 In X [rand.concept.urng], we have the following:
40897 <blockquote><pre>concept UniformRandomNumberGenerator<typename G> : Callable<G> {
40899 axiom NonemptyRange(G& g) {
40900 G::min() < G::max();
40904 </pre></blockquote>
40907 Since the parameter <tt>G</tt> is in scope throughout the concept, there is no
40908 need for the axiom to be further parameterized, and so the axiom can be
40909 slightly simplified as:
40912 <blockquote><pre>axiom NonemptyRange() {
40913 G::min() < G::max();
40915 </pre></blockquote>
40918 We can further reformulate so as to avoid any axiom machinery as:
40921 <blockquote><pre>requires True< G::min() < G::max() >;
40922 </pre></blockquote>
40925 This is not only a simpler statement of the same requirement, but also
40926 forces the requirement to be checked.
40935 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
40939 <p><b>Proposed resolution:</b></p>
40941 In X [rand.concept.urng], replace the <tt>NonemptyRange</tt> axiom by:
40944 <blockquote><pre><del>axiom NonemptyRange(G& g) {
40945 G::min() < G::max();
40947 <ins>requires True< G::min() < G::max() >;</ins>
40948 </pre></blockquote>
40956 <h3><a name="1150"></a>1150. wchar_t, char16_t and char32_t filenames</h3>
40957 <p><b>Section:</b> 27.9.1.14 [fstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
40958 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
40959 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
40960 <p><b>Discussion:</b></p>
40961 <p><b>Addresses JP 73</b></p>
40963 <p><b>Description</b></p>
40965 from C++98, <tt>fstream</tt> cannot appoint a filename of wide
40966 character string(<tt>const wchar_t</tt> and <tt>const wstring&</tt>).</p>
40967 <p><b>Suggestion</b></p>
40969 interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
40972 2009-07-01 Alisdair notes that this is a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> which has more
40973 in-depth rationale.
40978 2009-09-21 Daniel adds:
40983 I suggest to mark this issue as NAD Future with the intend to
40984 solve the issue with a single file path c'tor template assuming
40985 a provision of a TR2 filesystem library.
40994 NAD Future. This is a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>.
40999 <p><b>Proposed resolution:</b></p>
41006 <h3><a name="1153"></a>1153. Standard library needs review for constructors to be
41007 explicit to avoid treatment as initializer-list constructor</h3>
41008 <p><b>Section:</b> 17 [library], 30 [thread], D [depr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
41009 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41010 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
41011 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
41012 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
41013 <p><b>Discussion:</b></p>
41015 <p><b>Addresses DE 2</b></p>
41017 <p><b>Description</b></p>
41018 <p>Marking a constructor with <tt>explicit</tt> has semantics
41019 even for a constructor with zero or several parameters:
41020 Such a constructor cannot be used with list-initialization
41021 in a copy-initialization context, see 13.3.1.7 [over.match.list]. The
41022 standard library apparently has not been reviewed for
41023 marking non-single-parameter constructors as <tt>explicit</tt>.</p>
41024 <p><b>Suggestion</b></p>
41025 <p>Consider marking zero-parameter and multi-parameter
41026 constructors <tt>explicit</tt> in classes that have at least one
41027 constructor marked <tt>explicit</tt> and that do not have an
41028 initializer-list constructor.</p>
41030 <p><b>Notes</b></p>
41031 <p>Robert Klarer to address this one.</p>
41039 Move to "Open". Robert Klarer has promised to provide wording.
41043 2010 Pittsburgh: Moved to NAD, rationale added below.
41049 <p><b>Rationale:</b></p>
41051 We are unaware of any cases where initializer lists cause problem in this
41052 context, but if problems arise in the future the issue can be reopened.
41056 <p><b>Proposed resolution:</b></p>
41063 <h3><a name="1154"></a>1154. <tt>complex</tt> should accept integral types</h3>
41064 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
41065 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41066 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
41067 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
41068 <p><b>Discussion:</b></p>
41070 <p><b>Addresses FR 35</b></p>
41072 <p><b>Description</b></p>
41073 <p>Instantiations of the class
41074 template <tt>complex<></tt> have to be allowed for integral
41075 types, to reflect existing practice and ISO standards
41078 <p><b>Suggestion</b></p>
41081 2009-10-26 Proposed wording in
41082 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
41092 Moved to NAD Future. Rationale added.
41097 <p><b>Rationale:</b></p>
41099 There is no consensus for making this change at this time.
41103 <p><b>Proposed resolution:</b></p>
41105 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
41112 <h3><a name="1155"></a>1155. Reference should be to C99</h3>
41113 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41114 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41115 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
41116 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41117 <p><b>Discussion:</b></p>
41119 <p><b>Addresses FR 38</b></p>
41121 <p><b>Description</b></p>
41122 <p>What is ISO/IEC 1990:9899/DAM
41123 1? My guess is that's a typo for ISO/IEC
41124 9899/Amd.1:1995 which I'd
41125 have expected to be referenced here (the tables
41126 make reference to things
41127 which were introduced by Amd.1).</p>
41128 <p><b>Suggestion</b></p>
41129 <p>One need probably a reference
41130 to the document which introduce <tt>char16_t</tt> and
41131 <tt>char32_t</tt> in C (ISO/IEC TR 19769:2004?).</p>
41132 <p><b>Notes</b></p>
41133 <p>Create issue. Document in question should be C99, not C90+amendment1. The
41134 rest of the section requires careful review for completeness. Example <cstdint>
41135 18.4.1 [cstdint.syn]. Assign to C liasons.</p>
41138 2009-10 Santa Cruz:
41143 NAD Editorial. Already fixed.
41148 <p><b>Proposed resolution:</b></p>
41155 <h3><a name="1156"></a>1156. Constraints on bitmask and enumeration types to be tightened</h3>
41156 <p><b>Section:</b> 17.5.2.1.2 [enumerated.types], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
41157 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
41159 <p><b>Discussion:</b></p>
41161 <p><b>Addresses UK 165</b></p>
41163 <p><b>Description</b></p>
41165 bitmask and enumeration types were supposed to be tightened
41166 up as part of the motivation for the <tt>constexpr</tt> feature -
41168 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a>
41170 <p><b>Suggestion</b></p>
41171 <p>Adopt wording in line with the motivation
41173 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a></p>
41174 <p><b>Notes</b></p>
41175 <p>Robert Klarer to review</p>
41183 Move to Open. Ping Robert Klarer to provide wording, using N2235 as
41193 Moved to NAD. Rationale added.
41198 <p><b>Rationale:</b></p>
41200 UK NB did not sufficiently describe how to resolve their comment, and
41201 therefore we cannot make a change for the FCD. If a resolution were
41202 provided in the future, we would be happy to apply it.
41206 <p><b>Proposed resolution:</b></p>
41213 <h3><a name="1160"></a>1160. <tt>future_error</tt> public constructor is 'exposition only'</h3>
41214 <p><b>Section:</b> 30.6.3 [futures.future_error] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41215 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41216 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41217 <p><b>Discussion:</b></p>
41219 <p><b>Addresses UK 331</b></p>
41221 <p><b>Description</b></p>
41223 it means for a public constructor to be 'exposition only'.
41224 If the intent is purely to support the library calling this
41225 constructor then it can be made private and accessed
41226 through friendship. Otherwise it should be documented for
41227 public consumption.</p>
41228 <p><b>Suggestion</b></p>
41229 <p>Declare the constructor as private with a
41230 note about intended friendship, or remove the
41231 exposition-only comment and document the semantics.</p>
41232 <p><b>Notes</b></p>
41233 <p>Create an issue. Assigned to Detlef. Suggested resolution probably makes
41242 Pending a paper from Anthony Williams / Detleff Volleman.
41246 2009-10-14 Pending paper:
41247 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41252 2009-10 Santa Cruz:
41257 NAD Editorial. Solved by
41258 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41263 <p><b>Proposed resolution:</b></p>
41270 <h3><a name="1161"></a>1161. Unnecessary <tt>unique_future</tt> limitations</h3>
41271 <p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41272 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41273 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
41274 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41275 <p><b>Discussion:</b></p>
41277 <p><b>Addresses UK 336</b></p>
41279 <p><b>Description</b></p>
41282 to transfer ownership of the asynchronous result from one
41283 unique_future instance to another via the move-constructor.
41284 However, it is not possible to transfer it back, and nor is
41285 it possible to create a default-constructed unique_future
41286 instance to use as a later move target. This unduly limits
41287 the use of <tt>unique_future</tt> in code. Also, the lack of a
41288 move-assignment operator restricts the use of <tt>unique_future</tt>
41289 in containers such as <tt>std::vector</tt> - <tt>vector::insert</tt> requires
41290 move-assignable for example.</p>
41291 <p><b>Suggestion</b></p>
41292 <p>Add a default constructor with the
41293 semantics that it creates a <tt>unique_future</tt> with no
41294 associated asynchronous result. Add a move-assignment
41295 operator which transfers ownership.</p>
41296 <p><b>Notes</b></p>
41297 <p>Create an issue. Detlef will look into it.</p>
41305 Pending a paper from Anthony Williams / Detleff Volleman.
41309 2009-10-14 Pending paper:
41310 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41315 2009-10 Santa Cruz:
41320 NAD Editorial. Solved by
41321 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41326 <p><b>Proposed resolution:</b></p>
41333 <h3><a name="1162"></a>1162. <tt>shared_future</tt> should support an efficient move constructor</h3>
41334 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41335 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41336 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
41337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41338 <p><b>Discussion:</b></p>
41340 <p><b>Addresses UK 337</b></p>
41342 <p><b>Description</b></p>
41343 <p><tt>shared_future</tt>
41344 should support an efficient move constructor that can avoid
41345 unnecessary manipulation of a reference count, much like
41346 <tt>shared_ptr</tt></p>
41347 <p><b>Suggestion</b></p>
41348 <p>Add a move constructor</p>
41349 <p><b>Notes</b></p>
41350 <p>Create an issue. Detlef will look into it.</p>
41358 Pending a paper from Anthony Williams / Detleff Volleman.
41362 2009-10-14 Pending paper:
41363 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41368 2009-10 Santa Cruz:
41373 NAD Editorial. Solved by
41374 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41379 <p><b>Proposed resolution:</b></p>
41386 <h3><a name="1163"></a>1163. <tt>shared_future</tt> is inconsistent with <tt>shared_ptr</tt></h3>
41387 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41388 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41389 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
41390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41391 <p><b>Discussion:</b></p>
41393 <p><b>Addresses UK 338</b></p>
41395 <p><b>Description</b></p>
41397 <p><tt>shared_future</tt> is currently
41398 CopyConstructible, but not CopyAssignable. This is
41399 inconsistent with <tt>shared_ptr</tt>, and will surprise users.
41400 Users will then write work-arounds to provide this
41401 behaviour. We should provide it simply and efficiently as
41402 part of shared_future. Note that since the shared_future
41403 member functions for accessing the state are all declared
41404 const, the original usage of an immutable shared_future
41405 value that can be freely copied by multiple threads can be
41406 retained by declaring such an instance as "<tt>const
41407 shared_future</tt>".</p>
41408 <p><b>Suggestion</b></p>
41409 <p>Remove "=delete"
41410 from the copy-assignment operator of shared_future. Add a
41411 move-constructor <tt>shared_future(shared_future&&
41412 rhs)</tt>, and a move-assignment operator <tt>shared_future&
41413 operator=(shared_future&& rhs)</tt>. The postcondition
41414 for the copy-assignment operator is that <tt>*this</tt> has the same
41415 associated state as <tt>rhs</tt>. The postcondition for the
41416 move-constructor and move assignment is that <tt>*this</tt> has the
41417 same associated as <tt>rhs</tt> had before the
41418 constructor/assignment call and that <tt>rhs</tt> has no associated
41420 <p><b>Notes</b></p>
41421 <p>Create an issue. Detlef will look into it.</p>
41429 Pending a paper from Anthony Williams / Detleff Volleman.
41433 2009-10-14 Pending paper:
41434 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41439 2009-10 Santa Cruz:
41444 NAD Editorial. Solved by
41445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.htm">N2997</a>.
41450 <p><b>Proposed resolution:</b></p>
41457 <h3><a name="1164"></a>1164. <tt>promise::swap</tt> should pass by rvalue reference</h3>
41458 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
41459 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41460 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
41461 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
41462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
41463 <p><b>Discussion:</b></p>
41465 <p><b>Addresses UK 341</b></p>
41467 <p><b>Description</b></p>
41468 <p><tt>promise::swap</tt> accepts its parameter by lvalue reference. This is
41469 inconsistent with other types that provide a swap member function,
41470 where those swap functions accept an rvalue reference</p>
41472 <p><b>Suggestion</b></p>
41473 <p>Change <tt>promise::swap</tt> to take an rvalue reference.</p>
41475 <p><b>Notes</b></p>
41476 <p>Create an issue. Detlef will look into it. Probably ready as it.</p>
41484 NAD, by virtue of the changed rvalue rules and swap signatures from Summit.
41489 <p><b>Proposed resolution:</b></p>
41496 <h3><a name="1165"></a>1165. Unneeded promise move constructor</h3>
41497 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41498 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41499 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
41500 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
41501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41502 <p><b>Discussion:</b></p>
41504 <p><b>Addresses UK 343</b></p>
41506 <p><b>Description</b></p>
41507 <p>The move constructor of a std::promise
41508 object does not need to allocate any memory, so the
41509 move-construct-with-allocator overload of the constructor
41510 is superfluous.</p>
41511 <p><b>Suggestion</b></p>
41513 constructor with the signature <tt>template <class
41514 Allocator> promise(allocator_arg_t, const Allocator&
41515 a, promise& rhs);</tt></p>
41516 <p><b>Notes</b></p>
41517 <p>Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
41518 Note that
\93rhs
\94 argument should also be an rvalue reference in any case.</p>
41526 Pending a paper from Anthony Williams / Detleff Volleman.
41530 2009-10 Santa Cruz:
41535 NAD Editorial. Solved by
41536 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41541 <p><b>Proposed resolution:</b></p>
41548 <h3><a name="1166"></a>1166. Allocator-specific move/copy break model of move-constructor and
41549 move-assignment</h3>
41550 <p><b>Section:</b> X [allocator.propagation], X [allocator.propagation.map], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41551 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
41552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41553 <p><b>Discussion:</b></p>
41555 <p><b>Addresses US 77</b></p>
41557 <p><b>Description</b></p>
41558 <p>Allocator-specific move and copy behavior for containers
41559 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>) complicates a little-used and already-complicated
41560 portion of the standard library (allocators), and breaks
41561 the conceptual model of move-constructor and
41562 move-assignment operations on standard containers being
41563 efficient operations. The extensions for allocator-specific
41564 move and copy behavior should be removed from the working
41567 introduction of rvalue references, we are teaching
41568 programmers that moving from a standard container (e.g., a
41569 <tt>vector<string></tt>) is an efficient, constant-time
41570 operation. The introduction of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> removed that
41571 guarantee; depending on the behavior of four different
41572 traits (20.8.4), the complexity of copy and move operations
41573 can be constant or linear time. This level of customization
41574 greatly increases the complexity of standard containers,
41575 and benefits only a tiny fraction of the C++ community.</p>
41576 <p><b>Suggestion</b></p>
41578 <p>Remove 20.8.4.</p>
41580 <p>Remove 20.8.5.</p>
41582 <p>Remove all references to the facilities in
41583 20.8.4 and 20.8.5 from clause 23.</p>
41587 2009-10 Santa Cruz:
41592 NAD Editorial. Addressed by
41593 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
41598 <p><b>Proposed resolution:</b></p>
41605 <h3><a name="1167"></a>1167. <tt>pair<T,U></tt> doesn't model <tt>LessThanComparable</tt> in unconstrained code even if
41606 <tt>T</tt> and <tt>U</tt> do.</h3>
41607 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
41608 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2009-07-01 <b>Last modified:</b> 2010-10-23</p>
41609 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
41610 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
41611 <p><b>Discussion:</b></p>
41613 <tt>LessThanComparable</tt> requires (and provides default
41614 implementations for) <=,>, and >=. However, the defaults
41615 don't take effect in unconstrained code.
41618 Still, it's a problem to have types acting one way in
41619 constrained code and another in unconstrained code, except in cases of
41620 syntax adaptation. It's also inconsistent with the containers, which
41621 supply all those operators.
41625 Suggested Resolution:
41628 accept the exported concept maps proposal and
41629 change the way this stuff is handled to use an
41630 explicit exported concept map rather than nested
41634 e.g., remove from the body of <tt>std::list</tt>
41636 <blockquote><pre>template <LessThanComparable T, class Allocator>
41637 bool operator< (const list<T,Allocator>& x, const list<T,Allocator>& y);
41638 template <LessThanComparable T, class Allocator>
41639 bool operator> (const list<T,Allocator>& x, const list<T,Allocator>& y);
41640 template <LessThanComparable T, class Allocator>
41641 bool operator>=(const list<T,Allocator>& x, const list<T,Allocator>& y);
41642 template <LessThanComparable T, class Allocator>
41643 bool operator<=(const list<T,Allocator>& x, const list<T,Allocator>& y);
41644 </pre></blockquote>
41646 and add this concept_map afterwards:
41648 <blockquote><pre>template <LessThanComparable T, class Allocator>
41649 export concept_map LessThanComparable<list<T,Allocator> >
41651 bool operator<(const list<T,Allocator>& x, const list<T,Allocator>& y);
41653 </pre></blockquote>
41655 do similarly for <tt>std::pair</tt>. While you're at it, do the same for
41656 <tt>operator==</tt> and <tt>!=</tt> everywhere, and seek out other such opportunities.
41659 Alternative Resolution: keep the ugly, complex specification and add the
41660 missing operators to <tt>std::pair</tt>.
41664 <p><b>Proposed resolution:</b></p>
41671 <h3><a name="1168"></a>1168. Odd wording for bitset equality operators</h3>
41672 <p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41673 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-02 <b>Last modified:</b> 2010-10-23</p>
41674 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
41675 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41676 <p><b>Discussion:</b></p>
41678 The following wording seems a little unusual to me:
41681 p42/43 20.5.2 [bitset.members]
41685 <pre>bool operator==(const bitset<N>& rhs) const;
41688 -42- <i>Returns:</i> A nonzero value if the value of each bit in
41689 <tt>*this</tt> equals the value of the corresponding bit in
41692 <pre>bool operator!=(const bitset<N>& rhs) const;
41695 -43- <i>Returns:</i> A nonzero value if <tt>!(*this == rhs)</tt>.
41700 "A nonzero value" may be well defined as equivalent to the literal '<tt>true</tt>'
41701 for Booleans, but the wording is clumsy. I suggest replacing "A nonzero value"
41702 with the literal '<tt>true</tt>' (in appropriate font) in each case.
41706 2009-07-24 Alisdair recommends NAD Editorial.
41711 2009-07-27 Pete adds:
41716 It's obviously editorial. There's no need for further discussion.
41720 2009-07-27 Howard sets to NAD Editorial.
41726 <p><b>Proposed resolution:</b></p>
41728 Change 20.5.2 [bitset.members] p42-43:
41732 <pre>bool operator==(const bitset<N>& rhs) const;
41735 -42- <i>Returns:</i> <del>A nonzero value</del> <ins><tt>true</tt></ins> if the value of each bit in
41736 <tt>*this</tt> equals the value of the corresponding bit in
41739 <pre>bool operator!=(const bitset<N>& rhs) const;
41742 -43- <i>Returns:</i> <del>A nonzero value</del> <ins><tt>true</tt></ins> if <tt>!(*this == rhs)</tt>.
41752 <h3><a name="1172"></a>1172. <tt>select_on_container_(copy|move)_construction</tt> over-constrained</h3>
41753 <p><b>Section:</b> X [allocator.concepts.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41754 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-07-08 <b>Last modified:</b> 2010-10-23</p>
41755 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41756 <p><b>Discussion:</b></p>
41758 I believe the two functions
41759 <tt>select_on_container_(copy|move)_construction()</tt> are over-constrained. For
41760 example, the return value of the "copy" version is (see
41761 X [allocator.concepts.members]/21):
41764 <i>Returns:</i> <tt>x</tt> if the allocator should propagate from the existing
41765 container to the new container on copy construction, otherwise <tt>X()</tt>.
41768 Consider the case where a user decides to provide an explicit concept
41769 map for Allocator to adapt some legacy allocator class, as he wishes to
41770 provide customizations that the <tt>LegacyAllocator</tt> concept map template
41771 does not provide. Now, although it's true that the legacy class is
41772 required to have a default constructor, the user might have reasons to
41773 prefer a different constructor to implement
41774 <tt>select_on_container_copy_construction()</tt>. However, the current wording
41775 requires the use of the default constructor.
41778 Moreover, it's not said explicitly that <tt>x</tt> is supposed to be the
41779 allocator of the existing container. A clarification would do no harm.
41783 2009-10 Santa Cruz:
41788 NAD Editorial. Addressed by
41789 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
41794 <p><b>Proposed resolution:</b></p>
41796 Replace X [allocator.concepts.members]/21 with:
41799 <blockquote><pre>X select_on_container_copy_construction(const X& x);
41802 -21- <i>Returns:</i> <del><tt>x</tt> if the allocator should propagate from the existing
41803 container to the new container on copy construction, otherwise <tt>X()</tt>.</del>
41804 <ins>an allocator object to be used by the new container on copy
41805 construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
41806 is being copied. The most obvious choices for the return value are <tt>x</tt>, if
41807 the allocator should propagate from the existing container, and <tt>X()</tt>.
41808 <i>
\97 end note</i>]</ins>
41813 Replace X [allocator.concepts.members]/25 with:
41816 <blockquote><pre>X select_on_container_move_construction(X&& x);
41819 -25- <i>Returns:</i> <del><tt>move(x)</tt> if the allocator should propagate from the existing
41820 container to the new container on move construction, otherwise <tt>X()</tt>.</del>
41821 <ins>an allocator object to be used by the new container on move
41822 construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
41823 is being moved. The most obvious choices for the return value are <tt>move(x)</tt>, if
41824 the allocator should propagate from the existing container, and <tt>X()</tt>.
41825 <i>
\97 end note</i>]</ins>
41835 <h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
41836 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
41837 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14 <b>Last modified:</b> 2010-11-24</p>
41838 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
41839 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
41840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
41841 <p><b>Discussion:</b></p>
41843 Issue: The <tt>CopyConstructible</tt> requirements are wishy-washy. It requires
41844 that the copy is "equivalent" to the original, but "equivalent" is never
41848 I believe this to be an example of a more general lack of rigor around
41849 copy and assignment, although I haven't done the research to dig up all
41853 It's a problem because if you don't know what <tt>CopyConstructible</tt> means,
41854 you also don't know what it means to copy a pair of <tt>CopyConstructible</tt>
41855 types. It doesn't prevent us from writing code, but it is a hole in our
41856 ability to understand the meaning of copy.
41859 Furthermore, I'm pretty sure that vector's copy constructor doesn't
41860 require the elements to be <tt>EqualityComparable</tt>, so that table is actually
41861 referring to some ill-defined notion of equivalence when it uses ==.
41870 Move to "Open". Dave is right that this is a big issue. Paper D2987
41871 ("Defining Move Special Member Functions", Bjarne Stroustrup and
41872 Lawrence Crowl) touches on this but does not solve it. This issue is
41873 discussed in Elements of Programming.
41883 This issue is quite vague, so it is difficult to know if and when it has been resolved.
41885 John Lakos wrote a paper covering this area a while back, and there is a real interest in providing some sort of clean-up in the future.
41887 We need a more clearly draughted issues with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard.
41889 Move to Tentatively NAD Future.
41893 Moved to NAD Future at 2010-11 Batavia
41899 <p><b>Proposed resolution:</b></p>
41906 <h3><a name="1176"></a>1176. Make <tt>thread</tt> constructor non-variadic</h3>
41907 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
41908 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18 <b>Last modified:</b> 2010-10-23</p>
41909 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
41910 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
41911 <p><b>Discussion:</b></p>
41913 The variadic <tt>thread</tt> constructor is causing controversy, e.g.
41914 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
41915 This issue has been created as a placeholder for this course of action.
41918 <blockquote><pre>template <class F<del>, class ...Args</del>> thread(F&& f<del>, Args&&... args</del>);
41919 </pre></blockquote>
41922 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> for wording which specifies an rvalue-ref signature but
41923 with "decay behavior", but using variadics.
41927 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
41928 Rationale added below.
41933 <p><b>Proposed resolution:</b></p>
41938 <p><b>Rationale:</b></p>
41940 The (tentative) concensus of the LWG is to keep the variadic thread constructor.
41948 <h3><a name="1179"></a>1179. Probably editorial in [structure.specifications]</h3>
41949 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
41950 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-07-21 <b>Last modified:</b> 2010-10-23</p>
41951 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
41952 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
41953 <p><b>Discussion:</b></p>
41955 While reviewing <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a> I noted that 17.5.1.4 [structure.specifications]/7 says:
41959 -7- Error conditions specify conditions where a function may fail. The
41960 conditions are listed, together with a suitable explanation, as the <tt>enum
41961 class errc</tt> constants (19.5) that could be used as an argument to
41962 function <tt>make_error_condition</tt> (19.5.3.6).
41966 This paragraph should mention <tt>make_error_code</tt> or the text "that
41967 could be used as an argument to function <tt>make_error_condition</tt>
41968 (19.5.3.6)" should be deleted. I believe this is editorial.
41972 2009-07-21 Chris adds:
41978 I'm not convinced there's a problem there, because as far as the "Error
41979 conditions" clauses are concerned, make_error_condition() is used by a
41980 user to test for the condition, whereas make_error_code is not. For
41984 <blockquote><pre>void foobar(error_code& ec = throws());
41985 </pre></blockquote>
41991 permission_denied - Insufficient privilege to perform operation.
41995 When a user writes:
41998 <blockquote><pre>error_code ec;
42000 if (ec == errc::permission_denied)
42002 </pre></blockquote>
42005 the implicit conversion <tt>errc->error_condition</tt> makes the if-test
42009 <blockquote><pre>if (ec == make_error_condition(errc::permission_denied))
42010 </pre></blockquote>
42013 On the other hand, if the user had written:
42016 <blockquote><pre>if (ec == make_error_code(errc::permission_denied))
42017 </pre></blockquote>
42020 the test is now checking for a specific error code. The test may
42021 evaluate to <tt>false</tt> even though <tt>foobar()</tt> failed due to the documented
42022 error condition "Insufficient privilege".
42036 What the WP says right now is literally true: these codes can be used as
42037 an argument to <tt>make_error_condition</tt>. (It is also true that they can be
42038 used as an argument to <tt>make_error_code</tt>, which the WP doesn't say.) Maybe
42039 it would be clearer to just delete "that could be used as an argument to
42040 function <tt>make_error_condition</tt>", since that fact is already implied by
42041 other things that we say. We believe that this is editorial.
42047 <p><b>Proposed resolution:</b></p>
42056 <h3><a name="1184"></a>1184. Feature request: dynamic bitset</h3>
42057 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
42058 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-29 <b>Last modified:</b> 2010-10-23</p>
42059 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
42060 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
42061 <p><b>Discussion:</b></p>
42063 Opened at Alisdair's request, steming from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.
42064 Alisdair recommends NAD Future.
42068 2009-10 Santa Cruz:
42073 NAD Future. We want a heap allocated bitset, but we don't have one today and
42074 don't have time to add one.
42079 <p><b>Proposed resolution:</b></p>
42086 <h3><a name="1185"></a>1185. iterator categories and output iterators</h3>
42087 <p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
42088 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31 <b>Last modified:</b> 2010-10-23</p>
42089 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
42090 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
42091 <p><b>Discussion:</b></p>
42093 (wording relative to
42094 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
42095 pending new working paper)
42099 According to p3 24.2 [iterator.requirements], Forward iterators,
42100 Bidirectional iterators and Random Access iterators all satisfy the
42101 requirements for an Output iterator:
42105 XXX iterators satisfy all the requirements of the input and output iterators
42106 and can be used whenever either kind is specified ...
42110 Meanwhile, p4 goes on to contradict this:
42114 Besides its category, a forward, bidirectional, or random access
42115 iterator can also be mutable or constant...
42119 ... Constant iterators do not satisfy the requirements for output iterators
42123 The latter seems to be the overriding concern, as the iterator tag
42124 hierarchy does not define <tt>forward_iterator_tag</tt> as multiply derived from
42125 both <tt>input_iterator_tag</tt> and <tt>output_iterator_tag</tt>.
42129 The work on concepts for iterators showed us that output iterator really
42130 is fundamentally a second dimension to the iterator categories, rather
42131 than part of the linear input -> forward -> bidirectional ->
42132 random-access sequence. It would be good to clear up these words to
42133 reflect that, and separately list output iterator requirements in the
42134 requires clauses for the appropriate algorithms and operations.
42138 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
42144 <p><b>Rationale:</b></p>
42147 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
42151 <p><b>Proposed resolution:</b></p>
42158 <h3><a name="1186"></a>1186. Forward list could model a stack</h3>
42159 <p><b>Section:</b> 23.5.3 [stack] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Concepts">NAD Concepts</a>
42160 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31 <b>Last modified:</b> 2010-10-23</p>
42161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Concepts">NAD Concepts</a> status.</p>
42162 <p><b>Discussion:</b></p>
42164 The library template <tt>forward_list</tt> could easily model the idea of a
42165 <tt>stack</tt>, where the operations work on the front of the list rather than
42166 the back. However, the standard library <tt>stack</tt> adaptor cannot support
42171 It would be relatively easy to write a partial specialization for <tt>stack</tt>
42172 to support <tt>forward_list</tt>, but that opens the question of which header to
42173 place it in. A much better solution would be to add a <tt>concept_map</tt> for
42174 the <tt>StackLikeContainer</tt> concept to the <tt><forward_list></tt> header and then
42175 everything just works, including a user's own further uses in a
42176 stack-like context.
42180 Therefore while I am submitting the issue now so that it is on record, I
42181 <em>strongly recommend</em> we resolve as "NAD Concepts" as any non-concepts
42182 based solution will be inferior to the final goal, and the feature is
42183 not so compelling it must be supported ahead of the concepts-based
42188 2009-11-02 Howard adds:
42193 Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
42197 <p><b>Rationale:</b></p>
42199 Any non-concepts based solution will be inferior to the final goal, and the
42200 feature is not so compelling it must be supported ahead of the concepts-based
42206 <p><b>Proposed resolution:</b></p>
42213 <h3><a name="1188"></a>1188. Unordered containers should have a minimum load factor as well as a maximum</h3>
42214 <p><b>Section:</b> 23.2.5 [unord.req], 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
42215 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10 <b>Last modified:</b> 2010-11-24</p>
42216 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
42217 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
42218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
42219 <p><b>Discussion:</b></p>
42221 Unordered associative containers have a notion of a maximum load factor:
42222 when the number of elements grows large enough, the containers
42223 automatically perform a rehash so that the number of elements per bucket
42224 stays below a user-specified bound. This ensures that the hash table's
42225 performance characteristics don't change dramatically as the size
42230 For similar reasons, Google has found it useful to specify a minimum
42231 load factor: when the number of elements shrinks by a large enough, the
42232 containers automatically perform a rehash so that the number of elements
42233 per bucket stays above a user-specified bound. This is useful for two
42234 reasons. First, it prevents wasting a lot of memory when an unordered
42235 associative container grows temporarily. Second, it prevents amortized
42236 iteration time from being arbitrarily large; consider the case of a hash
42237 table with a billion buckets and only one element. (This was discussed
42238 even before TR1 was published; it was TR issue 6.13, which the LWG
42239 closed as NAD on the grounds that it was a known design feature.
42240 However, the LWG did not consider the approach of a minimum load
42245 The only interesting question is when shrinking is allowed. In principle
42246 the cleanest solution would be shrinking on erase, just as we grow on
42247 insert. However, that would be a usability problem; it would break a
42248 number of common idioms involving erase. Instead, Google's hash tables
42249 only shrink on insert and rehash.
42253 The proposed resolution allows, but does not require, shrinking in
42254 rehash, mostly because a postcondition for rehash that involves the
42255 minimum load factor would be fairly complicated. (It would probably have
42256 to involve a number of special cases and it would probably have to
42257 mention yet another parameter, a minimum bucket count.)
42261 The current behavior is equivalent to a minimum load factor of 0. If we
42262 specify that 0 is the default, this change will have no impact on
42263 backward compatibility.
42273 This seems to a useful extension, but is too late for 0x.
42275 Move to Tentatively NAD Future.
42279 Moved to NAD Future at 2010-11 Batavia
42285 <p><b>Proposed resolution:</b></p>
42287 Add two new rows, and change rehash's postcondition in the unordered
42288 associative container requirements table in 23.2.5 [unord.req]:
42293 <caption>Table 87
\97 Unordered associative container requirements
42294 (in addition to container)</caption>
42297 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
42298 <th>Complexity</th>
42302 <tt>a.min_load_factor()</tt>
42308 Returns a non-negative number that the container attempts to keep the
42309 load factor greater than or equal to. The container automatically
42310 decreases the number of buckets as necessary to keep the load factor
42319 <td><ins><tt>a.min_load_factor(z)</tt></ins></td>
42320 <td><ins><tt>void</tt></ins></td>
42321 <td><ins>Pre: <tt>z</tt> shall be non-negative. Changes the container's minimum
42322 load factor, using <tt>z</tt> as a hint. [<i>Footnote:</i> the minimum
42323 load factor should be significantly smaller than the maximum.
42324 If <tt>z</tt> is too large, the implementation may reduce it to a more sensible value.]
42331 <td><tt>a.rehash(n)</tt></td>
42332 <td><tt>void</tt></td>
42334 Post: <ins><tt>a.bucket_count() >= n</tt>, and <tt>a.size() <= a.bucket_count()
42335 * a.max_load_factor()</tt>. [<i>Footnote:</i> It is intentional that the
42336 postcondition does not mention the minimum load factor.
42337 This member function is primarily intended for cases where the user knows
42338 that the container's size will increase soon, in which case the container's
42339 load factor will temporarily fall below <tt>a.min_load_factor()</tt>.]</ins>
42341 <tt>a.bucket_cout > a.size() / a.max_load_factor()</tt> and <tt>a.bucket_count()
42346 Average case linear in <tt>a.size()</tt>, worst case quadratic.
42353 Add a footnote to 23.2.5 [unord.req] p12:
42358 The insert members shall not affect the validity of references to
42359 container elements, but may invalidate all iterators to the container.
42360 The erase members shall invalidate only iterators and references to the
42365 [A consequence of these requirements is that while insert may change the
42366 number of buckets, erase may not. The number of buckets may be reduced
42367 on calls to insert or rehash.]
42368 </ins></blockquote>
42372 Change paragraph 13:
42376 The insert members shall not affect the validity of iterators if
42377 <del><tt>(N+n) < z * B</tt></del> <ins><tt>zmin * B <= (N+n) <= zmax * B</tt></ins>,
42378 where <tt>N</tt> is the number of elements in
42379 the container prior to the insert operation, <tt>n</tt> is the number of
42380 elements inserted, <tt>B</tt> is the container's bucket count,
42381 <ins><tt>zmin</tt> is the container's minimum load factor,</ins>
42382 and <tt>z<ins>max</ins></tt> is the container's maximum load factor.
42386 Add to the <tt>unordered_map</tt> class synopsis in section 23.7.1 [unord.map],
42387 the <tt>unordered_multimap</tt> class synopsis
42388 in 23.7.2 [unord.multimap], the <tt>unordered_set</tt> class synopsis in
42389 23.7.3 [unord.set], and the <tt>unordered_multiset</tt> class synopsis
42390 in 23.7.4 [unord.multiset]:
42393 <blockquote><pre><ins>
42394 float min_load_factor() const;
42395 void min_load_factor(float z);
42396 </ins></pre></blockquote>
42399 In 23.7.1.1 [unord.map.cnstr], 23.7.2.1 [unord.multimap.cnstr], 23.7.3.1 [unord.set.cnstr], and
42400 23.7.4.1 [unord.multiset.cnstr], change:
42404 ... <tt>max_load_factor()</tt> returns 1.0 <ins>and
42405 <tt>min_load_factor()</tt> returns 0</ins>.
42413 <h3><a name="1190"></a>1190. Setting the maximum load factor should return the previous value</h3>
42414 <p><b>Section:</b> 23.2.5 [unord.req], 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
42415 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10 <b>Last modified:</b> 2010-11-24</p>
42416 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
42417 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
42418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
42419 <p><b>Discussion:</b></p>
42421 The unordered associative container requirements table specifies that
42422 <tt>a.set_max_load_factor(z)</tt> has return type <tt>void</tt>. However, there is a
42423 useful piece of information to return: the previous value. Users who
42424 don't need it can always ignore it.
42434 The benefit seems minor, while breaking with the getter/setter idiom these overloads support.
42436 Move to Tentatively NAD.
42440 Moved to NAD at 2010-11 Batavia
42446 <p><b>Proposed resolution:</b></p>
42448 In the unordered associative container requirements table, change:
42453 <caption>Table 87
\97 Unordered associative container requirements
42454 (in addition to container)</caption>
42457 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
42458 <th>Complexity</th>
42462 <td><tt>a.max_load_factor(z)</tt></td>
42463 <td><tt><del>void</del> <ins>float</ins></tt></td>
42464 <td>Pre: <tt>z</tt> shall be positive. Changes the container's maximum
42465 <del>load</del> load factor, using <tt>z</tt> as a hint.
42466 <ins>Returns: the previous value of
42467 <tt>a.max_load_factor()</tt>.</ins>
42478 Change the return type of <tt>set_max_load_factor</tt>
42479 in the class synopses in 23.7.1 [unord.map], 23.7.2 [unord.multimap], 23.7.3 [unord.set],
42480 and 23.7.4 [unord.multiset].
42484 If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a> is also accepted, make the same changes for
42485 <tt>min_load_factor</tt>.
42493 <h3><a name="1196"></a>1196. move semantics undefined for priority_queue</h3>
42494 <p><b>Section:</b> 23.5.2.1 [priqueue.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
42495 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-19 <b>Last modified:</b> 2010-10-23</p>
42496 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
42497 <p><b>Discussion:</b></p>
42499 The class template <tt>priority_queue</tt> declares signatures for a move
42500 constructor and move assignment operator in its class definition.
42501 However, it does not provide a definition (unlike <tt>std::queue</tt>, and
42502 proposed resolution for <tt>std::stack</tt>.) Nor does it provide a text clause
42503 specifying their behaviour.
42507 2009-08-23 Daniel adds:
42512 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a> provides wording that solves this issue.
42516 2009-10 Santa Cruz:
42521 Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>.
42526 <p><b>Proposed resolution:</b></p>
42533 <h3><a name="1200"></a>1200. "surprising" <tt>char_traits<T>::int_type</tt> requirements</h3>
42534 <p><b>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
42535 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-09-03 <b>Last modified:</b> 2010-11-24</p>
42536 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
42537 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
42538 <p><b>Discussion:</b></p>
42540 The footnote for <tt>int_type</tt> in 21.2.2 [char.traits.typedefs] says that
42545 can be held in <tt>char_type</tt> then some iostreams implementations may give
42546 surprising results.
42550 This implies that <tt>int_type</tt> should be a superset of
42551 <tt>char_type</tt>. However, the requirements for <tt>char16_t</tt> and <tt>char32_t</tt> define
42552 <tt>int_type</tt> to be equal to <tt>int_least16_t</tt> and <tt>int_least32_t</tt> respectively.
42553 <tt>int_least16_t</tt> is likely to be the same size as <tt>char_16_t</tt>, which may lead
42554 to surprising behavior, even if <tt>eof()</tt> is not a valid UTF-16 code unit.
42555 The standard should not prescribe surprising behavior, especially
42556 without saying what it is (it's apparently not undefined, just
42557 surprising). The same applies for 32-bit types.
42561 I personally recommend that behavior be undefined if <tt>eof()</tt> is a member
42562 of <tt>char_type</tt>, and another type be chosen for <tt>int_type</tt> (my personal
42563 favorite has always been a <tt>struct {bool eof; char_type c;}</tt>).
42564 Alternatively, the exact results of such a situation should be defined,
42565 at least so far that I/O could be conducted on these types as long as
42566 the code units remain valid. Note that the argument that no one streams
42567 <tt>char16_t</tt> or <tt>char32_t</tt> is not really valid as it would be perfectly
42568 reasonable to use a <tt>basic_stringstream</tt> in conjunction with UTF character
42573 2009-10-28 Ganesh provides two possible resolutions and expresses a preference
42582 Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
42586 The member <tt>eof()</tt> shall return <del>an implementation-defined
42587 constant that cannot appear as a valid UTF-16 code unit</del>
42588 <ins><tt>UINT_LEAST16_MAX</tt> [<i>Note:</i> this value is guaranteed to
42589 be a permanently reserved UCS-2 code position if <tt>UINT_LEAST16_MAX ==
42590 0xFFFF</tt> and it's not a UCS-2 code position otherwise
\97 <i>end
42595 Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
42599 The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
42600 cannot appear as a Unicode code point</del>
42602 <tt>UINT_LEAST32_MAX</tt> [<i>Note:</i> this value is guaranteed to be a
42603 permanently reserved UCS-4 code position if <tt>UINT_LEAST32_MAX ==
42604 0xFFFFFFFF</tt> and it's not a UCS-4 code position otherwise
\97 <i>end
42610 In 21.2.3.2 [char.traits.specializations.char16_t], in the
42611 definition of <tt>char_traits<char16_t></tt> replace the definition of nested
42612 typedef <tt>int_type</tt> with:
42615 <blockquote><pre>namespace std {
42616 template<> struct char_traits<char16_t> {
42617 typedef char16_t char_type;
42618 typedef <del>uint_least16_t</del> <ins>uint_fast16_t</ins> int_type;
42620 </pre></blockquote>
42623 Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
42627 The member <tt>eof()</tt> shall return <del>an implementation-defined
42628 constant that cannot appear as a valid UTF-16 code unit</del>
42629 <ins><tt>UINT_FAST16_MAX</tt> [<i>Note:</i> this value is guaranteed to
42630 be a permanently reserved UCS-2 code position if <tt>UINT_FAST16_MAX ==
42631 0xFFFF</tt> and it's not a UCS-2 code position otherwise
\97 <i>end
42636 In 21.2.3.3 [char.traits.specializations.char32_t], in the
42637 definition of <tt>char_traits<char32_t></tt> replace the definition of nested
42638 typedef <tt>int_type</tt> with:
42641 <blockquote><pre>namespace std {
42642 template<> struct char_traits<char32_t> {
42643 typedef char32_t char_type;
42644 typedef <del>uint_least32_t</del> <ins>uint_fast32_t</ins> int_type;
42646 </pre></blockquote>
42649 Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
42653 The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
42654 cannot appear as a Unicode code point</del>
42656 <tt>UINT_FAST32_MAX</tt> [<i>Note:</i> this value is guaranteed to be a
42657 permanently reserved UCS-4 code position if <tt>UINT_FAST32_MAX ==
42658 0xFFFFFFFF</tt> and it's not a UCS-4 code position otherwise
\97 <i>end
42672 This seems an overspecification, and it is not clear what problem is being solved - these values can be used portably by using the named functions; there is no need for the value itself to be portable.
42674 Move to Tentatively NAD.
42678 Moved to NAD at 2010-11 Batavia
42684 <p><b>Proposed resolution:</b></p>
42693 <h3><a name="1201"></a>1201. Do we always want to unwrap <tt>ref</tt>-wrappers in <tt>make_tuple</tt></h3>
42694 <p><b>Section:</b> 20.4.2.4 [tuple.creation], 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
42695 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-05 <b>Last modified:</b> 2010-10-23</p>
42696 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
42697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
42698 <p><b>Discussion:</b></p>
42700 Spotting a recent thread on the boost lists regarding collapsing
42701 optional representations in <tt>optional<optional<T>></tt> instances, I wonder if
42702 we have some of the same issues with <tt>make_tuple</tt>, and now <tt>make_pair</tt>?
42706 Essentially, if my generic code in my own library is handed a
42707 <tt>reference_wrapper</tt> by a user, and my library in turn delegates some logic
42708 to <tt>make_pair</tt> or <tt>make_tuple</tt>, then I am going to end up with a <tt>pair</tt>/<tt>tuple</tt>
42709 holding a real reference rather than the intended reference wrapper.
42713 There are two things as a library author I can do at this point:
42718 document my library also has the same reference-wrapper behaviour as
42719 <tt>std::make_tuple</tt>
42722 roll my own <tt>make_tuple</tt> that does not unwrap rereferences, a lost
42723 opportunity to re-use the standard library.
42728 (There may be some metaprogramming approaches my library can use to wrap
42729 the <tt>make_tuple</tt> call, but all will be significantly more complex than
42730 simply implementing a simplified <tt>make_tuple</tt>.)
42734 Now I don't propose we lose this library facility, I think unwrapping
42735 references will be the common behaviour. However, we might want to
42736 consider adding another overload that does nothing special with
42737 <tt>ref</tt>-wrappers. Note that we already have a second overload of <tt>make_tuple</tt>
42738 in the library, called <tt>tie</tt>.
42742 2009-09-30 Daniel adds:
42748 I suggest to change the currently proposed paragraph for
42749 <tt>make_simple_pair</tt>
42752 <blockquote><pre>template<typename... Types>
42753 pair<typename decay<Types>::type...> make_simple_pair(Types&&... t);
42757 <del><i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.</del>
42758 <ins><i>Remarks:</i> The program shall be ill-formed, if
42759 <tt>sizeof...(Types) != 2</tt>.</ins>
42768 or alternatively (but with a slightly different semantic):
42773 <i>Remarks:</i> If <tt>sizeof...(Types) != 2</tt>, this function shall not
42774 participate in overload resolution.
42779 to follow a currently introduced style and because the library does
42780 not have yet a specific "<i>Type requirements</i>" element. If such thing
42781 would be considered as useful this should be done as a separate
42782 issue. Given the increasing complexity of either of these wordings
42783 it might be preferable to use the normal two-argument-declaration
42784 style again in either of the following ways:
42789 <pre>template<class T1, class T2>
42790 pair<typename decay<T1>::type, typename decay<T2>::type>
42791 make_simple_pair(T1&& t1, T2&& t2);
42795 <pre>template<class T1, class T2>
42796 pair<V1, V2> make_simple_pair(T1&& t1, T2&& t2);
42799 Let <tt>V1</tt> be <tt>typename decay<T1>::type</tt> and <tt>V2</tt> be
42800 <tt>typename decay<T2>::type</tt>.
42808 2009-10 post-Santa Cruz:
42813 Mark as Tentatively NAD Future.
42818 <p><b>Rationale:</b></p>
42820 Does not have sufficient support at this time. May wish to reconsider for a
42825 <p><b>Proposed resolution:</b></p>
42827 Add the following function to 20.3.5 [pairs] and signature in
42828 appropriate synopses:
42831 <blockquote><pre>template<typename... Types>
42832 pair<typename decay<Types>::type...> make_simple_pair(Types&&... t);
42836 <i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.
42839 <i>Returns:</i> <tt>pair<typename decay<Types>::type...>(std::forward<Types>(t)...)</tt>.
42845 Draughting note: I chose a variadic representation similar to <tt>make_tuple</tt>
42846 rather than naming both types as it is easier to read through the
42847 clutter of metaprogramming this way. Given there are exactly two
42848 elements, the committee may prefer to draught with two explicit template
42849 type parameters instead
42854 Add the following function to 20.4.2.4 [tuple.creation] and
42855 signature in appropriate synopses:
42858 <blockquote><pre>template<typename... Types>
42859 tuple<typename decay<Types>::type...> make_simple_tuple(Types&&... t);
42863 <i>Returns:</i> <tt>tuple<typename decay<Types>::type...>(std::forward<Types>(t)...)</tt>.
42873 <h3><a name="1202"></a>1202. <tt>integral_constant</tt> needs a spring clean</h3>
42874 <p><b>Section:</b> 20.7.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
42875 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-05 <b>Last modified:</b> 2010-10-23</p>
42876 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
42877 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
42878 <p><b>Discussion:</b></p>
42880 The specification of <tt>integral_constant</tt> has been inherited
42881 essentially unchanged from TR1:
42884 <blockquote><pre>template <class T, T v>
42885 struct integral_constant {
42886 static const T value = v;
42887 typedef T value_type;
42888 typedef integral_constant<T,v> type;
42890 </pre></blockquote>
42893 In light of 0x language changes there are several things we might
42894 consider changing, notably the form of specification for value.
42898 The current form requires a static data member have storage allocated
42899 for it, where we could now implement without this using the new enum
42903 <blockquote><pre>template <class T, T v>
42904 struct integral_constant {
42905 <b>enum : T { value = v };</b>
42906 typedef T value_type;
42907 typedef integral_constant type;
42909 </pre></blockquote>
42912 The effective difference between these two implementation is:
42917 No requirement to allocate storage for data member (which we hope but do
42918 not guarantee compilers strip today)
42922 You can no longer take the address of the constant as
42923 <tt>&integral_constant<T,v>::value;</tt>
42928 Also note the editorial change to drop the explicit qualification of
42929 <tt>integral_constant</tt> in the <tt>typedef type</tt>. This makes it quite clear we
42930 mean the current instantiation, and cannot be mistaken for a recursive
42935 Even if we don't mandate this implementation, it would be nice to give
42936 vendors freedom under QoI to choose their preferred representation.
42940 The other side of this issue is if we choose to retain the static
42941 constant form. In that case we should go further and insist on
42942 <tt>constexpr</tt>, much like we did throughout <tt>numeric_limits</tt>:
42945 <blockquote><pre>template <class T, T v>
42946 struct integral_constant {
42947 static <b>constexpr</b> T value = v;
42948 typedef T value_type;
42949 typedef integral_constant type;
42951 </pre></blockquote>
42954 [Footnote] It turns out <tt>constexpr</tt> is part of the Tentatively Ready
42955 resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>. I don't want to interfere with that issue, but
42956 would like a new issue to consider if the fixed-base enum implementation
42961 2009-09-05 Daniel adds:
42967 I think that the suggested resolution is incomplete and
42968 may have some possible unwanted side-effects. To understand
42969 why, note that <tt>integral_constant</tt> is <em>completely</em> specified
42970 by code in 20.7.3 [meta.help]. While this is usually considered
42971 as a good thing, let me give a possible user-defined
42972 specialization that would break given the suggested changes:
42975 <blockquote><pre>enum NodeColor { Red, Black };
42977 std::integral_constant<NodeColor, Red> red;
42978 </pre></blockquote>
42981 The reason why that breaks is due to the fact that
42982 current core language rules does only allow integral
42983 types as enum-bases, see 7.2 [dcl.enum]/2.
42987 So, I think that we cannot leave the implementation the
42988 freedom to decide which way they would like to provide
42989 the implementation, because that is easily user-visible
42990 (I don't speak of addresses, but of instantiation errors),
42991 therefore if applied, this should be either specified or
42992 wording must be added that gives a note about this
42993 freedom of implementation.
42997 Another possible disadvantage seems to me that user-expectations
42998 are easy to disappoint if they see a failure
43002 <blockquote><pre>assert(typeid(std::integral_constant<int, 0>::value) == typeid(int));
43003 </pre></blockquote>
43009 <blockquote><pre>static_assert(std::is_same<decltype(std::integral_constant<int, 0>::value), const int>::value, "Bad library");
43010 </pre></blockquote>
43015 2010-01-14 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
43021 <p><b>Rationale:</b></p>
43023 We think that the suggested resolution is incomplete and may have some possible
43024 unwanted side-effects. (see Daniel's 2009-09-05 comment for details).
43028 <p><b>Proposed resolution:</b></p>
43035 <h3><a name="1203"></a>1203. More useful rvalue stream insertion</h3>
43036 <p><b>Section:</b> 27.7.2.9 [ostream.rvalue], 27.7.1.6 [istream.rvalue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
43037 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-06 <b>Last modified:</b> 2010-10-23</p>
43038 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
43039 <p><b>Discussion:</b></p>
43041 27.7.2.9 [ostream.rvalue] was created to preserve the ability to insert
43042 into (and extract from 27.7.1.6 [istream.rvalue]) rvalue streams:
43045 <blockquote><pre>template <class charT, class traits, class T>
43046 basic_ostream<charT, traits>&
43047 operator<<(basic_ostream<charT, traits>&& os, const T& x);
43051 1 <i>Effects:</i> <tt>os << x</tt>
43054 2 <i>Returns:</i> <tt>os</tt>
43060 This is good as it allows code that wants to (for example) open, write to, and
43061 close an <tt>ofstream</tt> all in one statement:
43064 <blockquote><pre>std::ofstream("log file") << "Some message\n";
43065 </pre></blockquote>
43068 However, I think we can easily make this "rvalue stream helper" even easier to
43069 use. Consider trying to quickly create a formatted string. With the current
43070 spec you have to write:
43073 <blockquote><pre>std::string s = static_cast<std::ostringstream&>(std::ostringstream() << "i = " << i).str();
43074 </pre></blockquote>
43077 This will store "<tt>i = 10</tt>" (for example) in the string <tt>s</tt>. Note
43078 the need to cast the stream back to <tt>ostringstream&</tt> prior to using
43079 the member <tt>.str()</tt>. This is necessary because the inserter has cast
43080 the <tt>ostringstream</tt> down to a more generic <tt>ostream</tt> during the
43085 I believe we can re-specify the rvalue-inserter so that this cast is unnecessary.
43086 Thus our customer now has to only type:
43089 <blockquote><pre>std::string s = (std::ostringstream() << "i = " << i).str();
43090 </pre></blockquote>
43093 This is accomplished by having the rvalue stream inserter return an rvalue of
43094 the same type, instead of casting it down to the base class. This is done by
43095 making the stream generic, and constraining it to be an rvalue of a type derived
43096 from <tt>ios_base</tt>.
43100 The same argument and solution also applies to the inserter. This code has been
43101 implemented and tested.
43110 NAD Future. No concensus for change.
43115 <p><b>Proposed resolution:</b></p>
43117 Change 27.7.1.6 [istream.rvalue]:
43120 <blockquote><pre>template <class <del>charT, class traits</del> <ins>Istream</ins>, class T>
43121 <del>basic_istream<charT, traits>&</del> <ins>Istream&&</ins>
43122 operator>>(<del>basic_istream<charT, traits></del> <ins>Istream</ins>&& is, T& x);
43126 1 <i>Effects:</i> <tt>is >> x</tt>
43129 2 <i>Returns:</i> <tt><ins>std::move(</ins>is<ins>)</ins></tt>
43132 3 <i>Remarks:</i> This signature shall participate in overload resolution if
43133 and only if <tt>Istream</tt> is not an lvalue reference type and is derived from
43140 Change 27.7.2.9 [ostream.rvalue]:
43143 <blockquote><pre>template <class <del>charT, class traits</del> <ins>Ostream</ins>, class T>
43144 <del>basic_ostream<charT, traits>&</del> <ins>Ostream&&</ins>
43145 operator<<(<del>basic_ostream<charT, traits></del> <ins>Ostream</ins>&& os, const T& x);
43149 1 <i>Effects:</i> <tt>os << x</tt>
43152 2 <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
43155 3 <i>Remarks:</i> This signature shall participate in overload resolution if
43156 and only if <tt>Ostream</tt> is not an lvalue reference type and is derived from
43168 <h3><a name="1210"></a>1210. iterator reachability should not require a container</h3>
43169 <p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
43170 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18 <b>Last modified:</b> 2010-10-23</p>
43171 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
43172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
43173 <p><b>Discussion:</b></p>
43175 p6 Iterator requirements 24.2 [iterator.requirements]
43179 An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
43180 there is a finite sequence of applications of the expression <tt>++i</tt> that
43181 makes <tt>i == j</tt>. If <tt>j</tt> is reachable from <tt>i</tt>, they refer to the same
43186 A good example would be stream iterators, which do not refer to a
43187 container. Typically, the end iterator from a range of stream iterators
43188 will compare equal for many such ranges. I suggest striking the second
43193 An alternative wording might be:
43197 If <tt>j</tt> is reachable from <tt>i</tt>, and both <tt>i</tt> and
43198 <tt>j</tt> are dereferencable iterators, then they refer to the same
43203 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
43209 <p><b>Rationale:</b></p>
43212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43216 <p><b>Proposed resolution:</b></p>
43218 Change 24.2 [iterator.requirements], p6:
43222 An iterator <tt>j</tt> is called <i>reachable</i> from an iterator
43223 <tt>i</tt> if and only if there is a finite sequence of applications of
43224 the expression <tt>++i</tt> that makes <tt>i == j</tt>. <del>If
43225 <tt>j</tt> is reachable from <tt>i</tt>, they refer to the same
43234 <h3><a name="1211"></a>1211. move iterators should be restricted as input iterators</h3>
43235 <p><b>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
43236 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18 <b>Last modified:</b> 2010-10-23</p>
43237 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#move.iterator">issues</a> in [move.iterator].</p>
43238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
43239 <p><b>Discussion:</b></p>
43241 I contend that while we can support both bidirectional and random access
43242 traversal, the category of a move iterator should never be better than
43243 <tt>input_iterator_tag</tt>.
43247 The contentious point is that you cannot truly have a multipass property
43248 when values are moved from a range. This is contentious if you view a
43249 moved-from object as still holding a valid value within the range.
43253 The second reason comes from the Forward Iterator requirements table:
43258 Forward iterators 24.2.5 [forward.iterators]
43262 Table 102 -- Forward iterator requirements
43266 For expression <tt>*a</tt> the return type is:
43267 "<tt>T&</tt> if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>"
43272 There is a similar constraint on <tt>a->m</tt>.
43276 There is no support for rvalue references, nor do I believe their should
43277 be. Again, opinions may vary but either this table or the definition of
43278 <tt>move_iterator</tt> need updating.
43282 Note: this requirement probably need updating anyway if we wish to
43283 support proxy iterators but I am waiting to see a new working paper
43284 before filing that issue.
43288 2009-10 post-Santa Cruz:
43293 Move to Open. Howard to put his rationale mentioned above into the issue
43298 2009-10-26 Howard adds:
43304 <tt>vector::insert(pos, iter, iter)</tt> is significantly more effcient when
43305 <tt>iter</tt> is a random access iterator, as compared to when it is an
43310 When <tt>iter</tt> is an input iterator, the best algorithm
43311 is to append the inserted range to the end of the <tt>vector</tt> using
43312 <tt>push_back</tt>. This may involve several reallocations before the input
43313 range is exhausted. After the append, then one can use <tt>std::rotate</tt>
43314 to place the inserted range into the correct position in the vector.
43318 But when <tt>iter</tt> is a random access iterator, the best algorithm
43319 is to first compute the size of the range to be inserted (<tt>last - first</tt>),
43320 do a buffer reallocation if necessary, scoot existing elements in the <tt>vector</tt>
43321 down to make the "hole", and then insert the new elements directly to their correct
43326 The insert-with-random-access-iterators algorithm is considerably more efficient
43327 than the insert-with-input-iterators algorithm
43334 <blockquote><pre>vector<A> v;
43335 <font color="#C80000">// ... build up a large vector of A ...</font>
43336 vector<A> temp;
43337 <font color="#C80000">// ... build up a large temporary vector of A to later be inserted ...</font>
43338 typedef move_iterator<vector<A>::iterator> MI;
43339 <font color="#C80000">// Now insert the temporary elements:</font>
43340 v.insert(v.begin() + N, MI(temp.begin()), MI(temp.end()));
43341 </pre></blockquote>
43344 A major motivation for using <tt>move_iterator</tt> in the above example is the
43345 expectation that <tt>A</tt> is cheap to move but expensive to copy. I.e. the
43346 customer is looking for <em>high performance</em>. If we allow <tt>vector::insert</tt>
43347 to subtract two <tt>MI</tt>'s to get the distance between them, the customer enjoys
43348 substantially better performance, compared to if we say that <tt>vector::insert</tt>
43349 can not subtract two <tt>MI</tt>'s.
43353 I can find no rationale for not giving this performance boost to our customers.
43354 Therefore I am strongly against restricting <tt>move_iterator</tt> to the
43355 <tt>input_iterator_tag</tt> category.
43359 I believe that the requirement that forward
43360 iterators have a dereference that returns an lvalue reference to cause unacceptable
43361 pessimization. For example <tt>vector<bool>::iterator</tt> also does not return
43362 a <tt>bool&</tt> on dereference. Yet I am not aware of a single vendor that
43363 is willing to ship <tt>vector<bool>::iterator</tt> as an input iterator.
43364 Everyone classifies it as a random access iterator. Not only does this not
43365 cause any problems, it prevents significant performance problems.
43371 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
43377 <p><b>Rationale:</b></p>
43380 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43384 <p><b>Proposed resolution:</b></p>
43386 Class template move_iterator 24.5.3.1 [move.iterator]
43389 <blockquote><pre>namespace std {
43390 template <class Iterator>
43391 class move_iterator {
43394 typedef <del>typename iterator_traits<Iterator>::iterator_category</del> <ins>input_iterator_tag</ins> iterator_category;
43395 </pre></blockquote>
43402 <h3><a name="1212"></a>1212. result of post-increment/decrement operator</h3>
43403 <p><b>Section:</b> 24.2 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
43404 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18 <b>Last modified:</b> 2010-10-23</p>
43405 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
43406 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
43407 <p><b>Discussion:</b></p>
43409 Forward iterator and bidirectional iterator place different requirements on the result of post-increment/decrement operator. The same form should be used in each case.
43416 <blockquote><pre>Table 102 -- Forward iterator requirements
43417 Table 103 -- Bidirectional iterator requirements
43419 r++ : convertible to const X&
43420 r-- : convertible to const X&
43422 *r++ : T& if X is mutable, otherwise const T&
43423 *r-- : convertible to T
43424 </pre></blockquote>
43427 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
43433 <p><b>Rationale:</b></p>
43436 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43440 <p><b>Proposed resolution:</b></p>
43447 <h3><a name="1217"></a>1217. Quaternion support</h3>
43448 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
43449 <b>Submitter:</b> Ted Shaneyfelt <b>Opened:</b> 2009-09-26 <b>Last modified:</b> 2010-10-23</p>
43450 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
43451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
43452 <p><b>Discussion:</b></p>
43454 Concerning mathematically proper operation of the type:
43457 <blockquote><pre>complex<complex<T> >
43458 </pre></blockquote>
43461 Generally accepted mathematical semantics of such a construct correspond
43462 to quaternions through Cayly-Dickson construct
43465 <blockquote><pre>(w+xi) + (y+zi) j
43466 </pre></blockquote>
43469 The proper implementation seems straightforward by adding a few
43470 declarations like those below. I have included operator definition for
43471 combining real scalars and complex types, as well, which seems
43472 appropriate, as algebra of complex numbers allows mixing complex and
43473 real numbers with operators. It also allows for constructs such as
43474 <tt>complex<double> i=(0,1), x = 12.34 + 5*i;</tt>
43478 Quaternions are often used in areas such as computer graphics, where,
43479 for example, they avoid the problem of Gimbal lock when rotating objects
43480 in 3D space, and can be more efficient than matrix multiplications,
43481 although I am applying them to a different field.
43484 <pre>/////////////////////////ALLOW OPERATORS TO COMBINE REAL SCALARS AND COMPLEX VALUES /////////////////////////
43485 template<typename T,typename S> complex<T> operator+(const complex<T> x,const S a) {
43486 complex<T> result(x.real()+a, x.imag());
43489 template<typename T,typename S> complex<T> operator+(const S a,const complex<T> x) {
43490 complex<T> result(a+x.real(), x.imag());
43493 template<typename T,typename S> complex<T> operator-(const complex<T> x,const S a) {
43494 complex<T> result(x.real()-a, x.imag());
43497 template<typename T,typename S> complex<T> operator-(const S a,const complex<T> x) {
43498 complex<T> result(a-x.real(), x.imag());
43501 template<typename T,typename S> complex<T> operator*(const complex<T> x,const S a) {
43502 complex<T> result(x.real()*a, x.imag()*a);
43505 template<typename T,typename S> complex<T> operator*(const S a,const complex<T> x) {
43506 complex<T> result(a*x.real(), a*x.imag());
43510 /////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS/////////////////////////
43511 template<typename T> double normSq(const complex<complex<T> >q) {
43512 return q.real().real()*q.real().real()
43513 + q.real().imag()*q.real().imag()
43514 + q.imag().real()*q.imag().real()
43515 + q.imag().imag()*q.imag().imag();
43517 template<typename T> double norm(const complex<complex<T> >q) {
43518 return sqrt(normSq(q));
43520 /////// Cayley-Dickson Construction
43521 template<typename T> complex<complex<T> > conj(const complex<complex<T> > x) {
43522 complex<complex<T> > result(conj(x.real()),-x.imag());
43525 template<typename T> complex<complex<T> > operator*(const complex<complex<T> > ab,const complex<complex<T> > cd) {
43526 complex<T> re(ab.real()*cd.real()-conj(cd.imag())*ab.imag());
43527 complex<T> im(cd.imag()*ab.real()+ab.imag()*conj(cd.real()));
43528 complex<complex<double> > q(re,im);
43531 //// Quaternion division
43532 template<typename S,typename T> complex<complex<T> > operator/(const complex<complex<T> > q,const S a) {
43535 template<typename S,typename T> complex<complex<T> > operator/(const S a,const complex<complex<T> > q) {
43536 return a*conj(q)/normSq(q);
43538 template<typename T> complex<complex<T> > operator/(const complex<complex<T> > n, const complex<complex<T> > d) {
43539 return n * (conj(d)/normSq(d));
43544 2009-10 Santa Cruz:
43549 NAD Future. There is no consensus or time to move this into C++0X.
43554 <p><b>Proposed resolution:</b></p>
43561 <h3><a name="1219"></a>1219. unique_lock::lock and resource_deadlock_would_occur</h3>
43562 <p><b>Section:</b> 30.4.2.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
43563 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
43564 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
43565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
43566 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a></p>
43567 <p><b>Discussion:</b></p>
43572 <tt>unique_lock::lock</tt> and friends raise
43573 "<tt>resource_deadlock_would_occur</tt> -- if the current thread already
43574 owns the mutex (i.e., on entry, <tt>owns</tt> is <tt>true</tt>)." 1)
43575 The current thread owning a mutex is not the same as any particular
43576 <tt>unique_lock::owns</tt> being <tt>true</tt>. 2) There's no need to
43577 raise this exception for a <tt>recursive_mutex</tt> if <tt>owns</tt> is
43578 <tt>false</tt>. 3) If <tt>owns</tt> is true, we need to raise some
43579 exception or the unique_lock will lose track of whether to unlock itself
43580 on destruction, but "deadlock" isn't it. For (3), s/bool owns/int
43581 ownership_level/ would fix it.
43585 2009-11-11 Alisdair notes that this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a>,
43591 2009-11-14 Moved to Tentatively Dup after 5 positive votes on c++std-lib.
43597 <p><b>Proposed resolution:</b></p>
43604 <h3><a name="1223"></a>1223. condition_variable_any lock matching?</h3>
43605 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
43606 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
43607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
43608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
43609 <p><b>Discussion:</b></p>
43611 For <tt>condition_variable_any</tt>, must all lock arguments to concurrent wait calls
43612 "match" in some way, similar to the requirement in
43613 30.5.1 [thread.condition.condvar] that <tt>lock.mutex()</tt> returns the same
43614 value for each of the lock arguments supplied by all concurrently
43615 waiting threads (via <tt>wait</tt> or <tt>timed_wait</tt>)?
43619 2010-02-12 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
43620 Rationale added below.
43626 <p><b>Rationale:</b></p>
43628 The rationale is that it doesn't matter, and you can't check: the lock types may
43629 be different, or the same and user-defined, so the implementation must provide
43630 internal synchronization anyway.
43634 <p><b>Proposed resolution:</b></p>
43641 <h3><a name="1224"></a>1224. condition_variable_any support for recursive mutexes?</h3>
43642 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
43643 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
43644 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
43645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
43646 <p><b>Discussion:</b></p>
43648 For <tt>condition_variable_any</tt>, are recursive mutexes allowed? (I think "no")
43652 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
43653 Rationale added below.
43658 <p><b>Proposed resolution:</b></p>
43661 <p><b>Rationale:</b></p>
43663 <tt>condition_variable_any::wait</tt> accepts any type of mutex. It calls
43664 <tt>unlock</tt> precisely once on entry and <tt>lock</tt> precisely once on
43665 exit. It is up to the user to ensure that this provides the required
43666 synchronization. Use of a recursive mutex is safe if either its lock count is 1,
43667 so after the single unlock it can be acquired by another thread, or another
43668 mechanism is used to synchronize the data.
43676 <h3><a name="1225"></a>1225. C++0x result_of issue </h3>
43677 <p><b>Section:</b> X [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
43678 <b>Submitter:</b> Sebastian Gesemann <b>Opened:</b> 2009-10-05 <b>Last modified:</b> 2010-10-23</p>
43679 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.ret">issues</a> in [func.ret].</p>
43680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
43681 <p><b>Discussion:</b></p>
43683 I think the text about <tt>std::result_of</tt> could be a little more precise.
43685 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>...
43690 X [func.ret] Function object return types
43693 <pre>template<class> class result_of;
43695 template<class Fn, class... ArgTypes>
43696 class result_of<Fn(ArgTypes...)> {
43698 typedef <i>see below</i> type;
43703 Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2,
43704 ..., tN</tt> of types <tt>T1, T2, ... TN</tt> in <tt>ArgTypes</tt>
43705 respectivly, the <tt>type</tt> member is the result type of the
43706 expression <tt>fn(t1,t2,...,tN)</tt>. the values <tt>ti</tt> are lvalues
43707 when the corresponding type <tt>Ti</tt> is an lvalue-reference type, and
43713 This text doesn't seem to consider lvalue reference types for <tt>Fn</tt>.
43714 Also, it's not clear whether this class template can be used for
43715 "SFINAE" like <tt>std::enable_if</tt>. Example:
43718 <blockquote><pre>template<typename Fn, typename... Args>
43719 typename std::result_of<Fn(Args...)>::type
43720 apply(Fn && fn, Args && ...args)
43722 // Fn may be an lvalue reference, too
43723 return std::forward<Fn>(fn)(std::forward<Args>(args)...);
43725 </pre></blockquote>
43728 Either <tt>std::result_of<...></tt> can be instantiated and simply may not have
43729 a typedef "<tt>type</tt>" (-->SFINAE) or instantiating the class template for
43730 some type combinations will be a "hard" compile-time error.
43734 2010-02-14 Daniel adds:
43739 This issue should be considered resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>. The wish to change <tt>result_of</tt> into a compiler-support
43740 trait was beyond the actual intention of the submitter Sebastian.
43744 2010 Pittsburgh: Moved to NAD Editorial, rationale added below.
43750 <p><b>Rationale:</b></p>
43752 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>.
43756 <p><b>Proposed resolution:</b></p>
43759 These changes will require compiler support
43764 Change X [func.ret]:
43767 <blockquote><pre>template<class> class result_of; // <i>undefined</i>
43769 template<class Fn, class... ArgTypes>
43770 class result_of<Fn(ArgTypes...)> {
43772 <del>typedef</del> <i>see below</i> <del>type;</del>
43777 Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2,
43778 ..., tN</tt> of types <tt>T1, T2, ... TN</tt> in <tt>ArgTypes</tt>
43779 respectivly, the <tt>type</tt> member is the result type of the
43780 expression <tt>fn(t1,t2,...,tN)</tt>. the values <tt>ti</tt> are lvalues
43781 when the corresponding type <tt>Ti</tt> is an lvalue-reference type, and
43786 <ins>The class template <tt>result_of</tt> shall meet the requirements of a
43787 <i>TransformationTrait</i>: Given the types <tt>Fn</tt>, <tt>T1</tt>, <tt>T2</tt>, ..., <tt>TN</tt> every
43788 template specialization <tt>result_of<Fn(T1,T2,...,TN)></tt> shall define the
43789 member typedef type equivalent to <tt>decltype(<i>RE</i>)</tt> if and only if
43790 the expression <tt><i>RE</i></tt>
43793 <blockquote><pre><ins>
43794 value<Fn>() ( value<T1>(), value<T2>(), ... value<TN>() )
43795 </ins></pre></blockquote>
43798 would be well-formed. Otherwise, there shall be no member typedef
43799 <tt>type</tt> defined.
43805 The <tt>value<></tt> helper function is a utility Daniel Krügler
43807 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>.
43816 <h3><a name="1226"></a>1226. Incomplete changes of #890</h3>
43817 <p><b>Section:</b> 30.6.2 [futures.errors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
43818 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-05 <b>Last modified:</b> 2010-10-23</p>
43819 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
43820 <p><b>Discussion:</b></p>
43822 Defect issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a> overlooked to adapt the <tt>future_category</tt> from
43823 30.6.1 [futures.overview] and 30.6.2 [futures.errors]:
43826 <blockquote><pre>extern const error_category* const future_category;
43827 </pre></blockquote>
43830 which should be similarly transformed into function form.
43839 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
43843 2009-11-11 Daniel adds:
43849 I just observe that the proposed resolution of this issue
43850 is incomplete and needs to reworded. The problem is that the
43851 corresponding declarations
43854 <blockquote><pre>constexpr error_code make_error_code(future_errc e);
43855 constexpr error_condition make_error_condition(future_errc e);
43856 </pre></blockquote>
43859 as constexpr functions are incompatible to the requirements of constexpr
43860 functions given their specified implementation. Note that the incompatibility
43861 is <em>not</em> a result of the modifications proposed by the issue resolution,
43862 but already existed within the
43863 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
43864 state where we have
43867 <blockquote><pre>extern const error_category* const future_category;
43868 </pre></blockquote>
43874 <blockquote><pre>constexpr error_code make_error_code(future_errc e);
43877 3 <i>Returns:</i> <tt>error_code(static_cast<int>(e), *future_category)</tt>.
43880 <pre>constexpr error_code make_error_condition(future_errc e);
43883 4 <i>Returns:</i> <tt>error_condition(static_cast<int>(e), *future_category)</tt>.
43888 Neither is any of the constructors of <tt>error_code</tt> and <tt>error_condition</tt>
43889 constexpr, nor does the expression <tt>*future_category</tt> satisfy the
43890 requirements for a constant expression (5.19 [expr.const]/2 bullet 6 in
43891 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>).
43895 The simple solution is just to remove the constexpr qualifiers for both
43896 functions, which makes sense, because none of the remaining <tt>make_error_*</tt>
43897 overloads in the library is constexpr. One might consider to realize that
43898 those <tt>make_*</tt> functions could satisfy the constexpr requirements, but this
43899 looks not like an easy task to me, because it would need to rely on a not
43900 yet existing language feature. If such a change is wanted, a new issue
43901 should be opened after the language extension approval (if at all) [1].
43905 If no-one complaints I would like to ask Howard to add the following
43906 modifications to this issue, alternatively a new issue could be opened but I
43907 don't know what the best solution is that would cause as little overhead
43911 What-ever the route is, the following is my proposed resolution for this issue
43912 interaction part of the story:
43917 In 30.6.1 [futures.overview]/1, Header <tt><future></tt> synopsis <em>and</em>
43918 in 30.6.2 [futures.errors]/3+4
43919 change as indicated:
43922 <blockquote><pre><del>constexpr</del> error_code make_error_code(future_errc e);
43923 <del>constexpr</del> error_condition make_error_condition(future_errc e);
43924 </pre></blockquote>
43928 [1] Let me add that we have a related NAD issue here: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>
43929 so the chances for realization are little IMO.
43933 Howard: I've updated the proposed wording as Daniel suggests and set to Review.
43939 2009-11-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
43949 Moved to NAD Editorial. Rationale added below.
43954 <p><b>Rationale:</b></p>
43960 <p><b>Proposed resolution:</b></p>
43964 Change in 30.6.1 [futures.overview], header <tt><future></tt> synopsis:
43967 <blockquote><pre><del>extern</del> const error_category<ins>&</ins><del>* const</del> future_category<ins>()</ins>;
43968 </pre></blockquote>
43973 In 30.6.1 [futures.overview]/1, Header <tt><future></tt> synopsis
43974 change as indicated:
43977 <blockquote><pre><del>constexpr</del> error_code make_error_code(future_errc e);
43978 <del>constexpr</del> error_condition make_error_condition(future_errc e);
43979 </pre></blockquote>
43984 Change in 30.6.2 [futures.errors]:
43987 <blockquote><pre><del>extern</del> const error_category<ins>&</ins><del>* const</del> future_category<ins>()</ins>;
43992 <del>1- <tt>future_category</tt> shall point to a statically initialized object
43993 of a type derived from class <tt>error_category</tt>.</del>
43996 <ins>1- <i>Returns:</i> A reference to an object of a type
43997 derived from class <tt>error_category</tt>.</ins>
44001 <pre><del>constexpr</del> error_code make_error_code(future_errc e);
44005 3 <i>Returns:</i> <tt>error_code(static_cast<int>(e),
44006 <del>*</del>future_category<ins>()</ins>)</tt>.
44009 <pre><del>constexpr</del> error_<del>code</del><ins>condition</ins> make_error_condition(future_errc e);
44013 4 <i>Returns:</i> <tt>error_condition(static_cast<int>(e),
44014 <del>*</del>future_category<ins>()</ins>)</tt>.
44025 <h3><a name="1228"></a>1228. User-specialized nothrow type traits</h3>
44026 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
44027 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-07 <b>Last modified:</b> 2010-10-23</p>
44028 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
44029 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
44030 <p><b>Discussion:</b></p>
44032 According to p1 20.7.2 [meta.type.synop]:
44036 The behavior of a program that adds specializations for any of the class
44037 templates defined in this subclause is undefined unless otherwise
44042 I believe we should 'otherwise specify' for the nothrow traits, are
44043 these are exactly the use cases where the end user actually has more
44044 information than the compiler.
44048 2009-10 Santa Cruz:
44053 Moved to Open. Definitely need to give the users the ability to ensure
44054 that the traits give the right answers. Unsure we want to give them the
44055 ability to say this in more than one way. Believes the noexcept proposal
44056 already gives this.
44060 2010 Pittsburgh: Moved to NAD, rationale added below.
44066 <p><b>Rationale:</b></p>
44068 We believe the solution offered by
44069 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html">N3050</a>
44074 <p><b>Proposed resolution:</b></p>
44076 Add the following comment:
44080 user specialization permitted to derive from <tt>std::true_type</tt> when the
44081 operation is known not to throw.
44085 to the following traits in 20.7.4.3 [meta.unary.prop] Table 43 Type
44086 property predicates.
44090 This may require a new Comments column
44094 <blockquote><pre>has_nothrow_default_constructor
44095 has_nothrow_copy_constructor
44097 </pre></blockquote>
44104 <h3><a name="1229"></a>1229. <tt>error_code operator=</tt> typo</h3>
44105 <p><b>Section:</b> 19.5.2.3 [syserr.errcode.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
44106 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-10-08 <b>Last modified:</b> 2010-10-23</p>
44107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
44108 <p><b>Discussion:</b></p>
44110 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
44111 19.5.2.1 [syserr.errcode.overview] and 19.5.2.3 [syserr.errcode.modifiers] say:
44115 template <class ErrorCodeEnum>
44116 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value>::type&
44117 operator=(ErrorCodeEnum e);
44118 </pre></blockquote>
44125 template <class ErrorCodeEnum>
44126 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type&
44127 operator=(ErrorCodeEnum e);
44128 </pre></blockquote>
44131 Or (I prefer this form):
44135 template <class ErrorCodeEnum>
44136 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code&>::type
44137 operator=(ErrorCodeEnum e);
44138 </pre></blockquote>
44141 This is because <tt>enable_if</tt> is declared as (20.7.7.6 [meta.trans.other]):
44145 template <bool B, class T = void> struct enable_if;
44146 </pre></blockquote>
44149 So, the current wording makes <tt>operator=</tt> return
44150 <tt>void&</tt>, which is not good.
44154 19.5.2.3 [syserr.errcode.modifiers]/4 says
44158 <i>Returns:</i> <tt>*this</tt>.
44169 19.5.3.1 [syserr.errcondition.overview]/1 says:
44173 template<typename ErrorConditionEnum>
44174 typename enable_if<is_error_condition_enum<ErrorConditionEnum>, error_code>::type &
44175 operator=( ErrorConditionEnum e );
44176 </pre></blockquote>
44179 Which contains several problems (<tt>typename</tt> versus <tt>class</tt>
44180 inconsistency, lack of <tt>::value</tt>, <tt>error_code</tt> instead of
44181 <tt>error_condition</tt>), while 19.5.3.3 [syserr.errcondition.modifiers] says:
44185 template <class ErrorConditionEnum>
44186 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type&
44187 operator=(ErrorConditionEnum e);
44188 </pre></blockquote>
44191 Which returns <tt>void&</tt>. They should both say:
44195 template <class ErrorConditionEnum>
44196 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type&
44197 operator=(ErrorConditionEnum e);
44198 </pre></blockquote>
44201 Or (again, I prefer this form):
44205 template <class ErrorConditionEnum>
44206 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition&>::type
44207 operator=(ErrorConditionEnum e);
44208 </pre></blockquote>
44211 Additionally, 19.5.3.3 [syserr.errcondition.modifiers] lacks a
44212 "<i>Returns:</i> <tt>*this</tt>." paragraph, which is presumably
44217 2009-10-18 Beman adds:
44222 The proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a> makes this issue
44223 moot, so it should become NAD.
44227 2009-10 Santa Cruz:
44232 NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.
44237 <p><b>Proposed resolution:</b></p>
44240 Change 19.5.2.1 [syserr.errcode.overview] and 19.5.2.3 [syserr.errcode.modifiers]:
44243 <blockquote><pre>template <class ErrorCodeEnum>
44244 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code&</ins>>::type<del>&</del>
44245 operator=(ErrorCodeEnum e);
44246 </pre></blockquote>
44249 Change 19.5.3.1 [syserr.errcondition.overview]:
44252 <blockquote><pre>template<<del>typename</del> <ins>class</ins> ErrorConditionEnum>
44253 typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>, error_co<ins>ndition</ins><del>de</del><ins>&</ins>>::type<del> &</del>
44254 operator=( ErrorConditionEnum e );
44255 </pre></blockquote>
44258 Change 19.5.3.3 [syserr.errcondition.modifiers]:
44261 <blockquote><pre>template <class ErrorConditionEnum>
44262 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value<ins>, error_condition&</ins>>::type<del>&</del>
44263 operator=(ErrorConditionEnum e);
44267 <i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
44270 <i>Returns:</i> <tt>*this</tt>.
44273 <i>Throws:</i> Nothing.
44284 <h3><a name="1230"></a>1230. <tt>mem_fn</tt> and variadic templates</h3>
44285 <p><b>Section:</b> 20.8.13 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
44286 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-09 <b>Last modified:</b> 2010-10-23</p>
44287 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
44288 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
44289 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a></p>
44290 <p><b>Discussion:</b></p>
44295 Since we have removed the entry in B [implimits] for the
44296 library-specific limit for number of arguments passed to
44297 <tt>function</tt>/<tt>tuple</tt>/etc. I believe we need to update the
44298 spec for <tt>mem_fn</tt> to reflect this.
44302 The "<i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set of
44303 overloaded function templates." no longer holds, as we cannot create an
44304 arbitrary number of such overloads. I believe we should strike the
44305 remark and add a second signature:
44308 <blockquote><pre>template<class R, class T, typename ... ArgTypes>
44309 unspecified mem_fn(R (T::*pm)(ArgTypes...));
44310 </pre></blockquote>
44313 I believe we need two signatures as pointer-to-data-member and
44314 pointer-to-member-function-taking-no-args appear to use subtly different
44319 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a> as a similar proposed resolution.
44324 <p><b>Proposed resolution:</b></p>
44325 Add to 20.8 [function.objects] and 20.8.13 [func.memfn]:
44328 <blockquote><pre>template<class R, class T> <i>unspecified</i> mem_fn(R T::* pm)
44330 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
44331 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
44332 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
44333 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>
44335 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&);</ins>
44336 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&);</ins>
44337 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&);</ins>
44338 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&);</ins>
44340 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&&);</ins>
44341 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&&);</ins>
44342 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&&);</ins>
44343 <ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&&);</ins>
44344 </pre></blockquote>
44347 Strike 20.8.13 [func.memfn], p5:
44351 <del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set
44352 of overloaded function templates.</del>
44359 <h3><a name="1232"></a>1232. Still <tt>swap</tt>'s with rvalue-references</h3>
44360 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
44361 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-11 <b>Last modified:</b> 2010-10-23</p>
44362 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
44363 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
44364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
44365 <p><b>Discussion:</b></p>
44367 The current library contains still rvalue reference-swaps that seem to be
44368 overlooked in the process of switching back to lvalue-ref swaps.
44372 2009-10 Santa Cruz:
44377 Editor accepts as NAD Editorial.
44382 <p><b>Proposed resolution:</b></p>
44386 Change 20.3.5 [pairs]/1 as indicated:
44389 <blockquote><pre>template <class T1, class T2>
44392 void swap(pair&<del>&</del> p);
44394 </pre></blockquote>
44399 Change 20.3.5 [pairs] before p. 17 as indicated:
44402 <blockquote><pre>void swap(pair&<del>&</del> p);
44403 </pre></blockquote>
44410 Change 20.3.5 [pairs] before p. 21 as indicated:
44413 <blockquote><pre>template<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>& y);
44414 <del>template<class T1, class T2> void swap(pair<T1, T2>&& x, pair<T1, T2>& y);</del>
44415 <del>template<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>&& y);</del>
44416 </pre></blockquote>
44422 Change 20.4.1 [tuple.general]/2, header <tt><tuple></tt> synopsis, as indicated:
44425 <blockquote><pre>// 20.5.2.9, specialized algorithms:
44426 template <class... Types>
44427 void swap(tuple<Types...>& x, tuple<Types...>& y);
44428 <del>template <class... Types>
44429 void swap(tuple<Types...>&& x, tuple<Types...>& y);
44430 template <class... Types>
44431 void swap(tuple<Types...>& x, tuple<Types...>&& y);</del>
44432 </pre></blockquote>
44438 Change 20.4.2 [tuple.tuple] as indicated:
44441 <blockquote><pre>// 20.5.2.3, tuple swap
44442 void swap(tuple&<del>&</del>)
44443 </pre></blockquote>
44449 Change 20.4.2.3 [tuple.swap] before 1 as indicated:
44452 <blockquote><pre>void swap(tuple&<del>&</del> rhs);
44453 </pre></blockquote>
44459 Change 20.8 [function.objects]/2, header <tt><functional></tt> synopsis, as indicated:
44462 <blockquote><pre>template<class R, class... ArgTypes>
44463 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
44464 <del>template<class R, class... ArgTypes>
44465 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
44466 template<class R, class... ArgTypes>
44467 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)&&);</del>
44468 </pre></blockquote>
44474 Change 20.8.14.2 [func.wrap.func], as indicated:
44477 <blockquote><pre>// 20.7.15.2.2, function modifiers:
44478 void swap(function&<del>&</del>);
44479 template<class F, class A> void assign(F, const A&);
44483 // 20.7.15.2.7, specialized algorithms:
44484 template <class R, class... ArgTypes>
44485 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
44486 <del>template <class R, class... ArgTypes>
44487 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
44488 template <class R, class... ArgTypes>
44489 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</del>
44490 </pre></blockquote>
44496 Change 20.8.14.2.7 [func.wrap.func.alg] before 1 as indicated:
44499 <blockquote><pre>template<class R, class... ArgTypes>
44500 void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>& f2);
44501 <del>template<class R, class... ArgTypes>
44502 void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
44503 template<class R, class... ArgTypes>
44504 void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</del>
44505 </pre></blockquote>
44511 Change 20.9.10.2 [util.smartptr.shared]/1 as indicated:
44514 <blockquote><pre>// 20.8.12.2.4, modifiers:
44515 void swap(shared_ptr&<del>&</del> r);
44519 // 20.8.12.2.9, shared_ptr specialized algorithms:
44520 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
44521 <del>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
44522 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</del>
44523 </pre></blockquote>
44529 Change 21.3 [string.classes]/1, header <tt><string></tt> synopsis, as indicated:
44532 <blockquote><pre>// 21.4.8.8: swap
44533 template<class charT, class traits, class Allocator>
44534 void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>& rhs);
44535 <del>template<class charT, class traits, class Allocator>
44536 void swap(basic_string<charT,traits,Allocator>&& lhs, basic_string<charT,traits,Allocator>& rhs);
44537 template<class charT, class traits, class Allocator>
44538 void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>&& rhs);</del>
44539 </pre></blockquote>
44545 Change 23.3 [sequences]/1, header <tt><deque></tt> synopsis, as indicated:
44548 <blockquote><pre>template <class T, class Allocator>
44549 void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);
44550 <del>template <class T, class Allocator>
44551 void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);
44552 template <class T, class Allocator>
44553 void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);</del>
44554 </pre></blockquote>
44560 Change 23.3 [sequences]/1, header <tt><list></tt> synopsis, as indicated:
44563 <blockquote><pre>template <class T, class Allocator>
44564 void swap(list<T,Allocator>& x, list<T,Allocator>& y);
44565 <del>template <class T, class Allocator>
44566 void swap(list<T,Allocator>&& x, list<T,Allocator>& y);
44567 template <class T, class Allocator>
44568 void swap(list<T,Allocator>& x, list<T,Allocator>&& y);</del>
44569 </pre></blockquote>
44575 Change 23.3 [sequences]/1, header <tt><queue></tt> synopsis, as indicated:
44578 <blockquote><pre>template <class T, class Allocator>
44579 void swap(queue<T, Container>& x, queue<T, Container>& y);
44580 <del>template <class T, class Container>
44581 void swap(queue<T, Container>&& x, queue<T, Container>& y);
44582 template <class T, class Container>
44583 void swap(queue<T, Container>& x, queue<T, Container>&& y);</del>
44585 template <class T, class Container = vector<T>, class Compare = less<typename Container::value_type> >
44586 class priority_queue;
44587 template <class T, class Container, class Compare>
44588 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);
44589 <del>template <class T, class Container, class Compare>
44590 void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);
44591 template <class T, class Container, class Compare>
44592 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);</del>
44593 </pre></blockquote>
44599 Change 23.3 [sequences]/1, header <tt><stack></tt> synopsis, as indicated:
44602 <blockquote><pre>template <class T, class Container>
44603 void swap(stack<T, Container>& x, stack<T, Container>& y);
44604 <del>template <class T, class Container>
44605 void swap(stack<T, Container>&& x, stack<T, Container>& y);
44606 template <class T, class Container>
44607 void swap(stack<T, Container>& x, stack<T, Container>&& y);</del>
44608 </pre></blockquote>
44614 Change 23.3 [sequences]/1, header <tt><vector></tt> synopsis, as indicated:
44617 <blockquote><pre>template <class T, class Allocator>
44618 void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);
44619 <del>template <class T, class Allocator>
44620 void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);
44621 template <class T, class Allocator>
44622 void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);</del>
44623 </pre></blockquote>
44629 Change 23.3.2 [deque]/2 as indicated:
44632 <blockquote><pre>iterator erase(const_iterator position);
44633 iterator erase(const_iterator first, const_iterator last);
44634 void swap(deque<T,Allocator>&<del>&</del>);
44639 // specialized algorithms:
44640 template <class T, class Allocator>
44641 void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);
44642 <del>template <class T, class Allocator>
44643 void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);
44644 template <class T, class Allocator>
44645 void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);</del>
44646 </pre></blockquote>
44652 Change 23.3.2.4 [deque.special] as indicated:
44655 <blockquote><pre>template <class T, class Allocator>
44656 void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);
44657 <del>template <class T, class Allocator>
44658 void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);
44659 template <class T, class Allocator>
44660 void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);</del>
44661 </pre></blockquote>
44667 Change 23.3.3 [forwardlist]/2 as indicated:
44670 <blockquote><pre>iterator erase_after(const_iterator position);
44671 iterator erase_after(const_iterator position, iterator last);
44672 void swap(forward_list<T,Allocator>&<del>&</del>);
44676 // 23.3.3.6 specialized algorithms:
44677 template <class T, class Allocator>
44678 void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y);
44679 <del>template <class T, class Allocator>
44680 void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y);
44681 template <class T, class Allocator>
44682 void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& y);</del>
44683 </pre></blockquote>
44689 Change 23.3.3.6 [forwardlist.spec] as indicated:
44692 <blockquote><pre>template <class T, class Allocator>
44693 void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y);
44694 <del>template <class T, class Allocator>
44695 void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y);
44696 template <class T, class Allocator>
44697 void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& y);</del>
44698 </pre></blockquote>
44704 Change 23.3.4 [list]/2 as indicated:
44707 <blockquote><pre>iterator erase(const_iterator position);
44708 iterator erase(const_iterator position, const_iterator last);
44709 void swap(list<T,Allocator>&<del>&</del>);
44714 // specialized algorithms:
44715 template <class T, class Allocator>
44716 void swap(list<T,Allocator>& x, list<T,Allocator>& y);
44717 <del>template <class T, class Allocator>
44718 void swap(list<T,Allocator>&& x, list<T,Allocator>& y);
44719 template <class T, class Allocator>
44720 void swap(list<T,Allocator>& x, list<T,Allocator>&& y);</del>
44721 </pre></blockquote>
44727 Change 23.3.4.5 [list.special] as indicated:
44730 <blockquote><pre>template <class T, class Allocator>
44731 void swap(list<T,Allocator>& x, list<T,Allocator>& y);
44732 <del>template <class T, class Allocator>
44733 void swap(list<T,Allocator>&& x, list<T,Allocator>& y);
44734 template <class T, class Allocator>
44735 void swap(list<T,Allocator>& x, list<T,Allocator>&& y);</del>
44736 </pre></blockquote>
44742 Change 23.5.1.1 [queue.defn] as indicated:
44745 <blockquote><pre>void swap(queue&<del>&</del> q) { c.swap(q.c); }
44749 template <class T, class Container>
44750 void swap(queue<T, Container>& x, queue<T, Container>& y);
44751 <del>template <class T, class Container>
44752 void swap(queue<T, Container>&& x, queue<T, Container>& y);
44753 template <class T, class Container>
44754 void swap(queue<T, Container>& x, queue<T, Container>&& y);</del>
44755 </pre></blockquote>
44761 Change 23.5.1.5 [queue.special] as indicated:
44764 <blockquote><pre>template <class T, class Container>
44765 void swap(queue<T, Container>& x, queue<T, Container>& y);
44766 <del>template <class T, class Container>
44767 void swap(queue<T, Container>&& x, queue<T, Container>& y);
44768 template <class T, class Container>
44769 void swap(queue<T, Container>& x, queue<T, Container>&& y);</del>
44770 </pre></blockquote>
44776 Change 23.5.2 [priority.queue]/1 as indicated:
44779 <blockquote><pre>void swap(priority_queue&<del>&</del>);
44781 // no equality is provided
44782 template <class T, class Container, class Compare>
44783 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);
44784 <del>template <class T, class Container, class Compare>
44785 void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);
44786 template <class T, class Container, class Compare>
44787 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);</del>
44788 </pre></blockquote>
44794 Change 23.5.2.4 [priqueue.special] as indicated:
44797 <blockquote><pre>template <class T, class Container, Compare>
44798 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);
44799 <del>template <class T, class Container, Compare>
44800 void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);
44801 template <class T, class Container, Compare>
44802 void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);</del>
44803 </pre></blockquote>
44809 Change 23.5.3.1 [stack.defn] as indicated:
44812 <blockquote><pre>void swap(stack&<del>&</del> s) { c.swap(s.c); }
44816 template <class T, class Allocator>
44817 void swap(stack<T,Allocator>& x, stack<T,Allocator>& y);
44818 <del>template <class T, class Allocator>
44819 void swap(stack<T,Allocator>&& x, stack<T,Allocator>& y);
44820 template <class T, class Allocator>
44821 void swap(stack<T,Allocator>& x, stack<T,Allocator>&& y);</del>
44822 </pre></blockquote>
44829 Change 23.5.3.5 [stack.special] as indicated:
44832 <blockquote><pre>template <class T, class Container>
44833 void swap(stack<T, Container>& x, stack<T, Container>& y);
44834 <del>template <class T, class Container>
44835 void swap(stack<T, Container>&& x, stack<T, Container>& y);
44836 template <class T, class Container>
44837 void swap(stack<T, Container>& x, stack<T, Container>&& y);</del>
44838 </pre></blockquote>
44844 Change 23.4.1 [vector]/2 as indicated:
44847 <blockquote><pre>void swap(vector<T,Allocator>&<del>&</del>);
44852 // specialized algorithms:
44853 template <class T, class Allocator>
44854 void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);
44855 <del>template <class T, class Allocator>
44856 void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);
44857 template <class T, class Allocator>
44858 void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);</del>
44859 </pre></blockquote>
44865 Change 23.4.1.2 [vector.capacity] before p. 8 as indicated:
44868 <blockquote><pre>void swap(vector<T,Allocator>&<del>&</del> x);
44869 </pre></blockquote>
44875 Change 23.4.1.5 [vector.special] as indicated:
44878 <blockquote><pre>template <class T, class Allocator>
44879 void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);
44880 <del>template <class T, class Allocator>
44881 void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);
44882 template <class T, class Allocator>
44883 void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);</del>
44884 </pre></blockquote>
44890 Change 23.4.2 [vector.bool]/1 as indicated:
44893 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44894 void swap(vector<bool,Allocator>&<del>&</del>);
44895 static void swap(reference x, reference y);
44896 </pre></blockquote>
44902 Change 23.6 [associative]/1, header <tt><map></tt> synopsis as indicated:
44905 <blockquote><pre>template <class Key, class T, class Compare, class Allocator>
44906 void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);
44907 <del>template <class Key, class T, class Compare, class Allocator>
44908 void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y);
44909 template <class Key, class T, class Compare, class Allocator>
44910 void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& y);</del>
44914 template <class Key, class T, class Compare, class Allocator>
44915 void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);
44916 <del>template <class Key, class T, class Compare, class Allocator>
44917 void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y);
44918 template <class Key, class T, class Compare, class Allocator>
44919 void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& y);</del>
44920 </pre></blockquote>
44926 Change 23.6 [associative]/1, header <tt><set></tt> synopsis as indicated:
44929 <blockquote><pre>template <class Key, class Compare, class Allocator>
44930 void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y);
44931 <del>template <class Key, class T, class Compare, class Allocator>
44932 void swap(set<Key,T,Compare,Allocator&& x, set<Key,T,Compare,Allocator>& y);
44933 template <class Key, class T, class Compare, class Allocator>
44934 void swap(set<Key,T,Compare,Allocator& x, set<Key,T,Compare,Allocator>&& y);</del>
44938 template <class Key, class Compare, class Allocator>
44939 void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);
44940 <del>template <class Key, class T, class Compare, class Allocator>
44941 void swap(multiset<Key,T,Compare,Allocator&& x, multiset<Key,T,Compare,Allocator>& y);
44942 template <class Key, class T, class Compare, class Allocator>
44943 void swap(multiset<Key,T,Compare,Allocator& x, multiset<Key,T,Compare,Allocator>&& y);</del>
44944 </pre></blockquote>
44950 Change 23.6.1 [map]/2 as indicated:
44953 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44954 void swap(map<Key,T,Compare,Allocator>&<del>&</del>);
44959 // specialized algorithms:
44960 template <class Key, class T, class Compare, class Allocator>
44961 void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);
44962 <del>template <class Key, class T, class Compare, class Allocator>
44963 void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y);
44964 template <class Key, class T, class Compare, class Allocator>
44965 void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& y);</del>
44966 </pre></blockquote>
44972 Change 23.6.1.5 [map.special] as indicated:
44975 <blockquote><pre>template <class Key, class T, class Compare, class Allocator>
44976 void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);
44977 <del>template <class Key, class T, class Compare, class Allocator>
44978 void swap(map<Key,T,Compare,Allocator>&& x, map<Key,T,Compare,Allocator>& y);
44979 template <class Key, class T, class Compare, class Allocator>
44980 void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>&& y);</del>
44981 </pre></blockquote>
44987 Change 23.6.2 [multimap]/2 as indicated:
44990 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44991 void swap(multimap<Key,T,Compare,Allocator>&<del>&</del>);
44996 // specialized algorithms:
44997 template <class Key, class T, class Compare, class Allocator>
44998 void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);
44999 <del>template <class Key, class T, class Compare, class Allocator>
45000 void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y);
45001 template <class Key, class T, class Compare, class Allocator>
45002 void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& y);</del>
45003 </pre></blockquote>
45009 Change 23.6.2.4 [multimap.special] as indicated:
45012 <blockquote><pre>template <class Key, class T, class Compare, class Allocator>
45013 void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);
45014 <del>template <class Key, class T, class Compare, class Allocator>
45015 void swap(multimap<Key,T,Compare,Allocator>&& x, multimap<Key,T,Compare,Allocator>& y);
45016 template <class Key, class T, class Compare, class Allocator>
45017 void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>&& y);</del>
45018 </pre></blockquote>
45024 Change 23.6.3 [set]/2 and 23.6.3.2 [set.special] as indicated: (twice!)
45027 <blockquote><pre>// specialized algorithms:
45028 template <class Key, class Compare, class Allocator>
45029 void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y);
45030 <del>template <class Key, class Compare, class Allocator>
45031 void swap(set<Key,Compare,Allocator&& x, set<Key,Compare,Allocator>& y);
45032 template <class Key, class Compare, class Allocator>
45033 void swap(set<Key,Compare,Allocator& x, set<Key,Compare,Allocator>&& y);</del>
45034 </pre></blockquote>
45040 Change 23.6.4 [multiset]/2 as indicated:
45043 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
45044 void swap(multiset<Key,Compare,Allocator>&<del>&</del>);
45049 // specialized algorithms:
45050 template <class Key, class Compare, class Allocator>
45051 void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);
45052 <del>template <class Key, class Compare, class Allocator>
45053 void swap(multiset<Key,Compare,Allocator&& x, multiset<Key,Compare,Allocator>& y);
45054 template <class Key, class Compare, class Allocator>
45055 void swap(multiset<Key,Compare,Allocator& x, multiset<Key,Compare,Allocator>&& y);</del>
45056 </pre></blockquote>
45062 Change 23.6.4.2 [multiset.special] as indicated:
45065 <blockquote><pre>template <class Key, class Compare, class Allocator>
45066 void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);
45067 <del>template <class Key, class Compare, class Allocator>
45068 void swap(multiset<Key,Compare,Allocator>&& x, multiset<Key,Compare,Allocator>& y);
45069 template <class Key, class Compare, class Allocator>
45070 void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>&& y);</del>
45071 </pre></blockquote>
45081 <h3><a name="1233"></a>1233. Missing <tt>unique_ptr</tt> signatures in synopsis</h3>
45082 <p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
45083 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-11 <b>Last modified:</b> 2010-10-23</p>
45084 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
45085 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
45086 <p><b>Discussion:</b></p>
45088 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>. Some <tt>unique_ptr</tt> signatures are missing
45089 from the synopsis in 20.9 [memory].
45093 2009-11-04 Howard adds:
45098 Moved to Tentatively NAD Editorial. The editor has adopted the fix.
45102 <p><b>Proposed resolution:</b></p>
45104 Add in 20.9 [memory], Header <tt><memory></tt> synopsis
45105 missing declarations as shown below:
45108 <blockquote><pre>// 20.8.11 Class unique_ptr:
45109 template <class X> class default_delete;
45110 <ins>template<class T> struct default_delete<T[]>;</ins>
45111 template <class X, class D = default_delete<T>> class unique_ptr;
45112 <ins>template<class T, class D> class unique_ptr<T[], D>;</ins>
45114 <ins>template<class T, class D> void swap(unique_ptr<T, D>& x, unique_ptr<T, D>& y);</ins>
45116 <ins>template<class T1, class D1, class T2, class D2>
45117 bool operator==(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45118 <ins>template<class T1, class D1, class T2, class D2>
45119 bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45120 <ins>template<class T1, class D1, class T2, class D2>
45121 bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45122 <ins>template<class T1, class D1, class T2, class D2>
45123 bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45124 <ins>template<class T1, class D1, class T2, class D2>
45125 bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45126 <ins>template<class T1, class D1, class T2, class D2>
45127 bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);</ins>
45128 </pre></blockquote>
45135 <h3><a name="1235"></a>1235. Issue with C++0x random number proposal</h3>
45136 <p><b>Section:</b> X [rand.concept.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
45137 <b>Submitter:</b> Matthias Troyer <b>Opened:</b> 2009-10-12 <b>Last modified:</b> 2010-10-23</p>
45138 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
45139 <p><b>Discussion:</b></p>
45141 There exist optimized, vectorized vendor libraries for the creation of
45142 random number generators, such as Intel's MKL [1] and AMD's ACML [2]. In
45143 timing tests we have seen a performance gain of a factor of up to 80
45144 (eighty) compared to a pure C++ implementation (in Boost.Random) when
45145 using these generator to generate a sequence of normally distributed
45146 random numbers. In codes dominated by the generation of random numbers
45147 (we have application codes where random number generation is more than
45148 50% of the CPU time) this factor 80 is very significant.
45152 To make use of these vectorized generators, we use a C++ class modeling
45153 the <tt>RandomNumberEngine</tt> concept and forwarding the generation of random
45154 numbers to those optimized generators. For example:
45157 <blockquote><pre>namespace mkl {
45158 class mt19937 {.... };
45160 </pre></blockquote>
45163 For the generation of random variates we also want to dispatch to
45164 optimized vectorized functions in the MKL or ACML libraries. See this
45168 <blockquote><pre>mkl::mt19937 eng;
45169 std::normal_distribution<double> dist;
45171 double n = dist(eng);
45172 </pre></blockquote>
45175 Since the variate generation is done through the <tt>operator()</tt> of the
45176 distribution there is no customization point to dispatch to Intel's or
45177 AMD's optimized functions to generate normally distributed numbers based
45178 on the <tt>mt19937</tt> generator. Hence, the performance gain of 80 cannot be
45183 Contrast this with TR1:
45186 <blockquote><pre>mkl::mt19937 eng;
45187 std::tr1::normal_distribution<double> dist;
45188 std::tr1::variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > rng(eng,dist);
45190 </pre></blockquote>
45193 This - admittedly much uglier from an aestethic point of view - design
45194 allowed optimization by specializing the <tt>variate_generator</tt> template for
45195 <tt>mkl::mt19937</tt>:
45198 <blockquote><pre>namespace std { namespace tr1 {
45201 class variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > { .... };
45204 </pre></blockquote>
45207 A similar customization point is missing in the C++0x design and
45208 prevents the optimized vectorized version to be used.
45212 Suggested resolution:
45216 Add a customization point to the distribution concept. Instead of the
45217 <tt>variate_generator</tt> template this can be done through a call to a
45218 free function <tt>generate_variate</tt> found by ADL instead of
45219 <tt>operator()</tt> of the distribution:
45222 <blockquote><pre>template <RandomNumberDistribution, class RandomNumberEngine>
45223 typename RandomNumberDistribution ::result_type
45224 generate_variate(RandomNumberDistribution const& dist, RandomNumberEngine& eng);
45225 </pre></blockquote>
45228 This function can be overloaded for optimized enginges like
45229 <tt>mkl::mt19937</tt>.
45233 2009-10 Santa Cruz:
45238 NAD Future. No time to add this feature for C++0X.
45243 <p><b>Proposed resolution:</b></p>
45250 <h3><a name="1236"></a>1236. reserved identifiers in programs not using the library</h3>
45251 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45252 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-10-13 <b>Last modified:</b> 2010-10-23</p>
45253 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
45254 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
45255 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45256 <p><b>Discussion:</b></p>
45258 I wasn't sure whether to consider this a library or a language issue,
45259 because the issue is I think it's incorrectly categorized as being part
45260 of the library, so I thought I'd send a message to both of you and let
45265 Most reserved identifiers are treated as unilaterally available to the
45266 implementation, such as to implement language extensions, or provide
45267 macros documenting its functionality. However, the requirements for
45268 reserved identifers are in 17.6.3.3 [reserved.names], which are a
45269 subsection of 17.6.3 [constraints]. 17.6.3.1 [constraints.overview] appears only to apply to "C++ programs
45270 that use the facilities of the C++ standard library", meaning that, in
45271 theory, all implementations are erroneous in having any non-standard
45272 identifiers predefined for programs that do not, at some point, include
45273 a standard library header.
45277 Furthermore, it's unclear whether the use of certain identifiers is UB
45278 or results in an ill-formed program. In particular, 17.6.3.3.1 [macro.names] uses a "shall not", where 17.6.3.3.2 [global.names] says that names are "reserved to the
45279 implementation". 17.6.3.3 [reserved.names] seems only to cover the
45280 instance of a name being described as "reserved", so are implementations
45281 required to diagnose a program that performs, as an example, "<tt>#undef
45291 Move to NAD. There may in theory be multiple interpretations possible,
45292 but there's no evidence that this causes any genuine problems or
45293 uncertainty about what implementations are allowed to do. We do not
45294 believe this rises to the level of a defect.
45299 <p><b>Proposed resolution:</b></p>
45306 <h3><a name="1238"></a>1238. defining algorithms taking iterator for range</h3>
45307 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
45308 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-15 <b>Last modified:</b> 2010-10-23</p>
45309 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
45310 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
45311 <p><b>Discussion:</b></p>
45313 The library has many algorithms that take a source range represented by
45314 a pair of iterators, and the start of some second sequence given by a
45315 single iterator. Internally, these algorithms will produce undefined
45316 behaviour if the second 'range' is not as large as the input range, but
45317 none of the algorithms spell this out in Requires clauses, and there is
45318 no catch-all wording to cover this in clause 17 or the front matter of
45323 There was an attempt to provide such wording in paper
45324 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a>
45326 seems incidental to the focus of the paper, and getting the wording of
45327 this issue right seems substantially more difficult than the simple
45328 approach taken in that paper. Such wording will be removed from an
45329 updated paper, and hopefully tracked via the LWG issues list instead.
45333 It seems there are several classes of problems here and finding wording
45334 to solve all in one paragraph could be too much. I suspect we need
45335 several overlapping requirements that should cover the desired range of
45340 Motivating examples:
45344 A good initial example is the <tt>swap_ranges</tt> algorithm. Here there is a
45345 clear requirement that <tt>first2</tt> refers to the start of a valid range at
45346 least as long as the range <tt>[first1, last1)</tt>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a> tries to solve this
45347 by positing a hypothetical <tt>last2</tt> iterator that is implied by the
45348 signature, and requires <tt>distance(first2,last2) < distance(first1,last1)</tt>.
45349 This mostly works, although I am uncomfortable assuming that <tt>last2</tt> is
45350 clearly defined and well known without any description of how to obtain
45351 it (and I have no idea how to write that).
45355 A second motivating example might be the <tt>copy</tt> algorithm. Specifically,
45356 let us image a call like:
45359 <blockquote><pre>copy(istream_iterator<int>(is),istream_iterator(),ostream_iterator<int>(os));
45360 </pre></blockquote>
45363 In this case, our input iterators are literally simple <tt>InputIterators</tt>,
45364 and the destination is a simple <tt>OutputIterator</tt>. In neither case am I
45365 happy referring to <tt>std::distance</tt>, in fact it is not possible for the
45366 <tt>ostream_iterator</tt> at all as it does not meet the requirements. However,
45367 any wording we provide must cover both cases. Perhaps we might deduce
45368 <tt>last2 == ostream_iterator<int>{}</tt>, but that might not always be valid for
45369 user-defined iterator types. I can well imagine an 'infinite range'
45370 that writes to <tt>/dev/null</tt> and has no meaningful <tt>last2</tt>.
45374 The motivating example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2944.pdf">n2944</a> is <tt>std::equal</tt>, and that seems to fall somewhere between the
45379 Outlying examples might be <tt>partition_copy</tt> that takes two output
45380 iterators, and the <tt>_n</tt> algorithms where a range is specified by a
45381 specific number of iterations, rather than traditional iterator pair.
45382 We should also <em>not</em> accidentally apply inappropriate constraints to
45383 <tt>std::rotate</tt> which takes a third iterator that is not intended to be a
45384 separate range at all.
45388 I suspect we want some wording similar to:
45392 For algorithms that operate on ranges where the end iterator of the
45393 second range is not specified, the second range shall contain at least
45394 as many elements as the first.
45398 I don't think this quite captures the intent yet though. I am not sure
45399 if 'range' is the right term here rather than sequence. More awkwardly,
45400 I am not convinced we can describe an Output sequence such as produce by
45401 an <tt>ostream_iterator</tt> as "containing elements", at least not as a
45402 precondition to the call before they have been written.
45406 Another idea was to describe require that the trailing iterator support
45407 at least distance(input range) applications of <tt>operator++</tt> and may be
45408 written through the same number of times if a mutable/output iterator.
45412 We might also consider handling the case of an output range vs. an input
45413 range in separate paragraphs, if that simplifies how we describe some of
45418 2009-11-03 Howard adds:
45423 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
45427 <p><b>Rationale:</b></p>
45429 Does not have sufficient support at this time. May wish to reconsider for a
45434 <p><b>Proposed resolution:</b></p>
45441 <h3><a name="1239"></a>1239. Defect report</h3>
45442 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
45443 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-10-16 <b>Last modified:</b> 2010-10-23</p>
45444 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
45445 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
45446 <p><b>Discussion:</b></p>
45448 Table 43 defines a number of traits that yield true for arrays of class
45449 types with the trait's property, but not arrays of other types with that
45450 property. For example, <tt>has_trivial_default_constructor</tt>:
45454 <tt>T</tt> is a trivial type (3.9) or a class type with a trivial default
45455 constructor (12.1) or an array of such a class type.
45459 2009-10 post-Santa Cruz:
45465 An array of a trivial type is a trivial type.
45468 Mark as Tentatively NAD Editorial. The wording is OK as is,
45469 since an array of a trivial type is a trivial type, but the wording as
45470 proposed might be clearer.
45476 <p><b>Rationale:</b></p>
45478 The wording is OK as is, since an array of a trivial type is a trivial type.
45479 Project editor may wish to accept the suggested wording as editorial.
45483 <p><b>Proposed resolution:</b></p>
45485 Change all the traits in question following this pattern:
45489 <tt>T</tt> is a trivial type (3.9) or a class type with a trivial default
45490 constructor (12.1)<ins>,</ins> or an array of such a <del>class</del> type.
45494 i.e., add a comma and delete a "class."
45502 <h3><a name="1242"></a>1242. Enable SCARY iterators</h3>
45503 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
45504 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2009-10-21 <b>Last modified:</b> 2010-10-23</p>
45505 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
45506 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
45507 <p><b>Discussion:</b></p>
45510 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2980.pdf">N2980</a>.
45514 <p><b>Proposed resolution:</b></p>
45521 <h3><a name="1243"></a>1243. Missing <tt>operator+= (initializer_list<T>)</tt> for <tt>valarray</tt></h3>
45522 <p><b>Section:</b> 26.6.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45523 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-22 <b>Last modified:</b> 2010-10-23</p>
45524 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cassign">issues</a> in [valarray.cassign].</p>
45525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45526 <p><b>Discussion:</b></p>
45527 <p><b>Addresses JP 64</b></p>
45530 During the additions of <tt>initializer_list</tt> overloads
45531 <tt>basic_string</tt> added
45534 <blockquote><pre>basic_string& operator+=(initializer_list<charT>);
45535 </pre></blockquote>
45541 <blockquote><pre>valarray<T>& operator+= (initializer_list<T>);
45542 </pre></blockquote>
45549 Daniel adds on opening:
45554 Recommend NAD. The <tt>operator+=</tt> overload of <tt>basic_string</tt>
45555 behaves as-if calling <tt>append</tt>, which is completely different in
45556 meaning as the existing <tt>operator+=</tt> overloads in
45557 <tt>valarray</tt> which just sum the value or values to the existing
45558 elements. The suggestion to add a corresponding append function to
45559 <tt>valarray</tt> was not considered as appropriate and the request was
45560 withdrawn (c++std-lib-24968).
45564 2009-10 Santa Cruz:
45569 Mark as NAD. Request has been withdrawn by NB.
45574 <p><b>Proposed resolution:</b></p>
45576 Add to 26.6.2.6 [valarray.cassign]:
45579 <blockquote><pre>valarray<T>& operator+= (initializer_list<T>);
45580 </pre></blockquote>
45587 <h3><a name="1244"></a>1244. wait_*() in *future for synchronous functions</h3>
45588 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
45589 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2009-10-22 <b>Last modified:</b> 2010-10-23</p>
45590 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
45591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
45592 <p><b>Discussion:</b></p>
45594 With the addition of <tt>async()</tt>, a <tt>future</tt> might be
45595 associated with a function that is not running in a different thread but
45596 is stored to by run synchronously on the <tt>get()</tt> call. It's not
45597 clear what the <tt>wait()</tt> functions should do in this case.
45601 Suggested resolution:
45605 Throw an exception.
45609 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
45615 <p><b>Rationale:</b></p>
45618 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
45622 <p><b>Proposed resolution:</b></p>
45629 <h3><a name="1246"></a>1246. <tt>vector::resize()</tt> missing efficiency guarantee</h3>
45630 <p><b>Section:</b> 23.4.1.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45631 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-10-24 <b>Last modified:</b> 2010-10-23</p>
45632 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
45633 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45634 <p><b>Discussion:</b></p>
45636 If <tt>v</tt> is a <tt>vector</tt>, I think repeated calls to
45637 <tt>v.resize( v.size() + 1 )</tt> should be amortized O(1), but it's not
45638 clear that's true from the text of the standard:
45641 <blockquote><pre>void resize(size_type sz);
45644 <i>Effects:</i> If <tt>sz < size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
45645 <tt>size() < sz</tt>, appends <tt>sz - size()</tt> default constructed elements to the
45651 Seems to me if we used <tt>push_back</tt> instead of appends, we might be giving
45652 the guarantee I'd like. Thoughts?
45656 2009-11-10 Howard adds:
45661 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added
45667 <p><b>Proposed resolution:</b></p>
45669 In 23.4.1.2 [vector.capacity]/10, change
45672 <blockquote><pre>void resize(size_type sz);
45675 <i>Effects:</i> If <tt>sz < size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
45676 <tt>size() < sz</tt>, <del>appends <tt>sz - size()</tt> default constructed elements to the
45678 <ins>equivalent to <tt>sz - size()</tt> consecutive evaluations of <tt>push_back(T())</tt></ins>.
45684 <p><b>Rationale:</b></p>
45686 The description in terms of <tt>push_back</tt> led some to believe that
45687 one could expect the exact same growth pattern from both <tt>resize</tt> and
45688 <tt>push_back</tt> (e.g.) which could lead to sub-optimal implementations.
45689 Additionally, 23.4.1 [vector], p1 includes a statement that this container
45690 "supports (amortized) constant time insert and erase operations at the end;",
45691 therefore addressing the concern of this issue.
45699 <h3><a name="1248"></a>1248. Equality comparison for unordered containers</h3>
45700 <p><b>Section:</b> 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
45701 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2009-10-25 <b>Last modified:</b> 2010-10-23</p>
45702 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
45703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
45704 <p><b>Discussion:</b></p>
45707 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
45711 2010-01-22 Alisdair Opens.
45716 2010-01-24 Alisdair provides wording.
45721 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
45727 <p><b>Rationale:</b></p>
45730 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3068.pdf">N3068</a>.
45734 <p><b>Proposed resolution:</b></p>
45737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
45745 <h3><a name="1251"></a>1251. move constructing <tt>basic_stringbuf</tt></h3>
45746 <p><b>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45747 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-29 <b>Last modified:</b> 2010-10-23</p>
45748 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.cons">issues</a> in [stringbuf.cons].</p>
45749 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45750 <p><b>Discussion:</b></p>
45752 I just came across issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a> -- Global permission to move, which
45753 seems to address the concern raised by the example in c++std-lib-25030.
45756 IIUC, the example violates the permission to assume that arguments
45757 bound to rvalue references are unnamed temporaries granted to
45758 implementations by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a> - Global permission
45763 I.e., the <tt>ostringstream(ostringstream &&rhs)</tt> ctor can leave the <tt>rhs</tt>
45764 pointers pointing to the newly constructed object's buffer just as
45765 long as the dtor doesn't change or invalidate the buffer. The caller
45766 may not make any assumptions about rhs after the move beyond it being
45767 safe to destroy or reassign.
45771 So unless I misunderstood something, I still think the <tt>basic_stringbuf</tt>
45772 move ctor is overspecified. Specifically, I think the third sentence
45773 in the Effects clause and the last 6 bullets in the Postconditions
45774 clause can, and IMO should, be stricken.
45778 2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
45779 Rationale added below.
45784 <p><b>Rationale:</b></p>
45786 The sense of 1251 appears to be that the <tt>basic_stringbuf</tt> move
45787 constructor offers more guarantees than the minimum. This is true, and quite
45788 correct. The additional words guarantee that the internal buffer has genuinely
45789 transferred from one object to another, and further operations on the original
45790 will not affect the buffer of the newly created object. This is a very
45791 important guarantee, much as we see that a moved-from <tt>unique_ptr</tt> is
45792 guaranteed to be empty.
45796 <p><b>Proposed resolution:</b></p>
45798 Strike from 27.8.1.1 [stringbuf.cons]:
45801 <blockquote><pre>basic_stringbuf(basic_stringbuf&& rhs);
45805 <i>Effects:</i> Move constructs from the rvalue <tt>rhs</tt>. It is
45806 implementation-defined whether the sequence pointers in <tt>*this</tt>
45807 (<tt>eback()</tt>, <tt>gptr()</tt>, <tt>egptr()</tt>, <tt>pbase()</tt>,
45808 <tt>pptr()</tt>, <tt>epptr()</tt>) obtain the values which <tt>rhs</tt>
45809 had. <del>Whether they do or not, <tt>*this</tt> and <tt>rhs</tt> reference
45810 separate buffers (if any at all) after the construction.</del> The openmode,
45811 locale and any other state of <tt>rhs</tt> is also copied.
45815 <i>Postconditions:</i> Let <tt>rhs_p</tt> refer to the state of
45816 <tt>rhs</tt> just prior to this construction and let <tt>rhs_a</tt>
45817 referto the state of <tt>rhs</tt> just after this construction.
45821 <tt>str() == rhs_p.str()</tt>
45824 <tt>gptr() - eback() == rhs_p.gptr() - rhs_p.eback()</tt>
45827 <tt>egptr() - eback() == rhs_p.egptr() - rhs_p.eback()</tt>
45830 <tt>pptr() - pbase() == rhs_p.pptr() - rhs_p.pbase()</tt>
45833 <tt>epptr() - pbase() == rhs_p.epptr() - rhs_p.pbase()</tt>
45836 if <tt>(eback()) eback() != rhs_a.eback()</tt>
45839 if <tt>(gptr()) gptr() != rhs_a.gptr()</tt>
45842 if <tt>(egptr()) egptr() != rhs_a.egptr()</tt>
45845 if <tt>(pbase()) pbase() != rhs_a.pbase()</tt>
45848 if <tt>(pptr()) pptr() != rhs_a.pptr()</tt>
45851 if <tt>(epptr()) epptr() != rhs_a.epptr()</tt>
45863 <h3><a name="1259"></a>1259. Should initializer-list constructors move elements?</h3>
45864 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45865 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-11-05 <b>Last modified:</b> 2010-10-23</p>
45866 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
45867 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45868 <p><b>Discussion:</b></p>
45870 According to 23.2.3 [sequence.reqmts], <tt>X(il)</tt> is
45871 equivalent to <tt>X(il.begin(), il.end())</tt>. Should it instead be
45872 equivalent to <tt>X(move_iterator(il.begin()),
45873 move_iterator(il.end()))</tt> so that needless copies are not made? This
45874 doesn't seem ideal either - it may make more sense to provide two
45875 overloads for the constructor, one for move and one for copy.
45879 2009-11-10 Howard adds:
45884 I've moved this issue to Tentatively NAD after 5 positive votes on c++std-lib,
45885 and added a rationale below.
45889 <p><b>Proposed resolution:</b></p>
45894 <p><b>Rationale:</b></p>
45896 There is no consensus at this time within EWG or CWG to make the
45897 required language changes. Therefore this is not something that the LWG
45898 can even consider. Should such language changes be made for a future
45899 standard, no doubt there would need to be an accompanying library impact
45908 <h3><a name="1263"></a>1263. missing <tt>swap</tt> overloads for <tt>regex</tt></h3>
45909 <p><b>Section:</b> 28.4 [re.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45910 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-11-12 <b>Last modified:</b> 2010-10-23</p>
45911 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45912 <p><b>Discussion:</b></p>
45914 <p><b>Addresses: UK 314</b></p>
45917 In Message c++std-lib-25529, Alisdair writes:
45922 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#UK314">UK comment 314</a>
45923 requests rvalue swap overloads in a couple of places they
45928 We have in general reverted to the single swap signature taking lvalue
45929 references, which could be seen as the alternative solution to
45930 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#UK314">UK 314</a>,
45931 bringing consistency to the standard <g>
45935 Either way, I no longer expect to see any work to resolve this comment -
45936 the work is complete and it should be either marked Rejected, or
45937 Accepted with Modifications (namely, removing all other rvalue swaps!)
45942 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
45947 <p><b>Proposed resolution:</b></p>
45950 <p><b>Rationale:</b></p>
45952 We have in general reverted to the single swap signature taking
45953 lvalue references, which could be seen as the alternative solution to
45954 UK 314, bringing consistency to the standard.
45962 <h3><a name="1265"></a>1265. <tt>longjmp</tt> and destructors</h3>
45963 <p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
45964 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-11-16 <b>Last modified:</b> 2010-10-23</p>
45965 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
45966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
45967 <p><b>Discussion:</b></p>
45969 18.10 [support.runtime]/4 says that <tt>longjmp</tt> is undefined if
45970 unwinding by the mechanism used by catch and throw would invoke any nontrivial
45971 destructors. However, the text as written is rather vague, in particular when
45972 dealing with <tt>catch(...)</tt>:
45975 <blockquote><pre>void foo() {
45977 non_trivial_dtor n1; // 1
45978 if (!setjmp(buf)) {
45979 non_trivial_dtor n2; // 2
45986 </pre></blockquote>
45989 My interpretation of the meaning of 18.10 [support.runtime]/4 is that
45990 declaration 2, but not 1, would cause the <tt>longjmp</tt> to be undefined
45991 behavior. However, it's not entirely clear from the text. Arguably, replacing
45992 the <tt>setjmp</tt> and <tt>longjmp</tt> with <tt>catch</tt> would still cause
45993 the destructor for <tt>n1</tt> to be called after the unwinding, which would
45994 lead to undefined behavior. This is clearly not an intended consequence of the
45995 wording. However, it is probably still UB, as <tt>n1</tt> now has
45996 "indeterminate" value, and running its destructor on <tt>foo</tt>'s exit will
46001 Declarations 2 has a more interesting issue. The <tt>catch(...)</tt> muddles up
46002 the definition that uses <tt>throw</tt> and <tt>catch</tt> - if
46003 <tt>longjmp()</tt> were indeed a <tt>throw</tt>, control would never return to
46004 the <tt>setjmp</tt>. As such, <tt>n2</tt>'s destructor wouldn't be called
46005 (except by the argument for <tt>n1</tt>, which is that the destructor would be
46006 called later as the frame was left in the normal control flow).
46010 I suggest that paragraph 4 of 18.10 [support.runtime] should be replaced
46011 with the following, or something that reads better but has the same effect:
46015 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
46016 restricted behavior in this International Standard. A call to <tt>longjmp</tt>
46017 has undefined behavior if any non-trivial destructors would be called were the
46018 <tt>longjmp</tt> call replaced with a throw-expression whose nearest matching
46019 handler were a (possibly imaginary) function-try-block on the function
46020 containing the corresponding <tt>setjmp</tt> call.
46024 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
46025 Rationale added below.
46030 <p><b>Proposed resolution:</b></p>
46032 Change 18.10 [support.runtime]/4:
46036 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
46037 restricted behavior in this International Standard. <del>A
46038 <tt>setjmp</tt>/<tt>longjmp</tt> call pair has undefined behavior if replacing
46039 the <tt>setjmp</tt> and <tt>longjmp</tt> by <tt>catch</tt> and <tt>throw</tt>
46040 would invoke any non-trivial destructors for any automatic objects.</del>
46041 <ins>A call to <tt>longjmp</tt> has undefined behavior if any non-trivial
46042 destructors would be called were the <tt>longjmp</tt> call replaced with a
46043 throw-expression whose nearest matching handler were a (possibly imaginary)
46044 function-try-block on the function containing the corresponding <tt>setjmp</tt>
46049 <p><b>Rationale:</b></p>
46051 In the given example, it is clear that it is only <tt>n2</tt> and not
46052 <tt>n1</tt> that is destroyed by the <tt>longjmp</tt>.
46055 At this late stage in the standards process, we are focusing on issues that
46056 impact users or implementers. Trying to rewrite complex wording just for the
46057 sake of improved clarity is likely to do more harm than good.
46065 <h3><a name="1266"></a>1266. <tt>shared_future::get</tt> and deferred async functions</h3>
46066 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46067 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17 <b>Last modified:</b> 2010-10-23</p>
46068 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
46069 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46070 <p><b>Discussion:</b></p>
46072 If a <tt>shared_future</tt> is constructed with the result of an <tt>async</tt> call with a
46073 deferred function, and two or more copies of that <tt>shared_future</tt> are created,
46074 with multiple threads calling <tt>get()</tt>, it is not clear which thread runs the
46075 deferred function. 30.6.7 [futures.shared_future]p22 from
46076 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
46077 says (minus editor's note):
46081 <i>Effects:</i> if the associated state contains a deferred function, executes
46082 the deferred function. Otherwise, blocks until the associated state is ready.
46086 In the absence of wording to the contrary, this implies that every thread that
46087 calls <tt>wait()</tt> will execute the deferred function.
46091 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
46097 <p><b>Rationale:</b></p>
46100 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46104 <p><b>Proposed resolution:</b></p>
46106 Replace 30.6.7 [futures.shared_future]p22 with the following:
46111 <i>Effects:</i> If the associated state
46112 <del>contains a deferred function, executes the deferred function. Otherwise,
46113 blocks until the associated state is ready.</del>
46114 <ins>was created by a <tt>promise</tt> or <tt>packaged_task</tt> object, block
46115 until the associated state is ready. If the associated state is associated with
46116 a thread created for an <tt>async</tt> call (30.6.9 [futures.async]), as
46117 if <tt>associated-thread.join()</tt>.
46121 If the associated state contains a deferred function, calls to <tt>wait()</tt>
46122 on all <tt>shared_future</tt> objects that share the same associated state are
46123 serialized. The first call to <tt>wait()</tt> that shares a given associated
46124 state executes the deferred function and stores the return value or exception in
46125 the associated state.
46129 <i>Synchronization:</i> if the associated state was created by a
46130 <tt>promise</tt> object, the completion of <tt>set_value()</tt> or
46131 <tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10 [intro.multithread]) <tt>wait()</tt> returns. If the associated state
46132 was created by a <tt>packaged_task</tt> object, the completion of the associated
46133 task happens before <tt>wait()</tt> returns. If the associated state is
46134 associated with a thread created for an <tt>async</tt> call (30.6.9 [futures.async]), the completion of the associated thread happens-before
46135 <tt>wait()</tt> returns.
46139 If the associated state contained a deferred function, the invocation of the
46140 deferred function happens-before any call to <tt>wait()</tt> on a
46141 <tt>future</tt> that shares that state returns.
46150 <h3><a name="1269"></a>1269. Associated state doesn't account for async</h3>
46151 <p><b>Section:</b> 30.6.4 [futures.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46152 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-18 <b>Last modified:</b> 2010-10-23</p>
46153 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.state">active issues</a> in [futures.state].</p>
46154 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.state">issues</a> in [futures.state].</p>
46155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46156 <p><b>Discussion:</b></p>
46158 The current description of the associated state in 30.6.4 [futures.state]
46159 does not allow for futures created by an <tt>async</tt> call. The description
46160 therefore needs to be extended to cover that.
46164 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
46170 <p><b>Rationale:</b></p>
46173 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46177 <p><b>Proposed resolution:</b></p>
46179 Add a new sentence to 30.6.4 [futures.state] p2:
46183 2 This <i>associated state</i> consists of some state information and some
46184 (possibly not yet evaluated) <i>result</i>, which can be a (possibly
46185 <tt>void</tt>) value or an exception. <ins>If the associated state was created
46186 by a call to <tt>async</tt> (30.6.9 [futures.async]) then it may also
46187 contain a deferred function or an associated <tt>thread</tt>.</ins>
46191 Add an extra bullet to 30.6.4 [futures.state] p3:
46196 The result of an associated state can be set by calling:
46200 <tt>promise::set_value</tt>,
46203 <tt>promise::set_exception</tt>, <del>or</del>
46206 packaged_task::operator()<del>.</del><ins>, or</ins>
46209 <ins>a call to <tt>async</tt> (30.6.9 [futures.async]).</ins>
46219 <h3><a name="1272"></a>1272. confusing declarations of <tt>promise::set_value</tt></h3>
46220 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46221 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-22 <b>Last modified:</b> 2010-10-23</p>
46222 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
46223 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
46224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46225 <p><b>Discussion:</b></p>
46227 The definitions of <tt>promise::set_value</tt> need tidying up, the
46231 <blockquote><pre>// setting the result
46232 void set_value(const R& r);
46233 void set_value(<i>see below</i>);
46234 </pre></blockquote>
46237 Why is the first one there? It implies it is always present for all
46238 specialisations of promise, which is not true.
46242 The definition says:
46245 <blockquote><pre>void set_value(const R& r);
46246 void promise::set_value(R&& r);
46247 void promise<R&>::set_value(R& r);
46248 void promise<void>::set_value();
46249 </pre></blockquote>
46252 The lack of qualification on the first one again implies it's present
46253 for all specialisations, again not true.
46257 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
46263 <p><b>Rationale:</b></p>
46266 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46270 <p><b>Proposed resolution:</b></p>
46272 Change the synopsis in 30.6.5 [futures.promise]:
46275 <blockquote><pre>// setting the result
46276 <del>void set_value(const R& r);</del>
46277 void set_value(<i>see below</i>);
46278 </pre></blockquote>
46281 And the definition be changed by qualifying the first signature:
46284 <blockquote><pre>void <ins>promise::</ins>set_value(const R& r);
46285 void promise::set_value(R&& r);
46286 void promise<R&>::set_value(R& r);
46287 void promise<void>::set_value();
46288 </pre></blockquote>
46295 <h3><a name="1273"></a>1273. <tt>future::valid</tt> should be callable on an invalid future</h3>
46296 <p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46297 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-22 <b>Last modified:</b> 2010-10-23</p>
46298 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
46299 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46300 <p><b>Discussion:</b></p>
46302 30.6.6 [futures.unique_future]/3 says:
46306 The effect of calling any member function other than the destructor or
46307 the move-assignment operator on a <tt>future</tt> object for which <tt>valid() ==
46308 false</tt> is undefined.
46312 This means calling <tt>future::valid()</tt> is undefined unless it will
46313 return <tt>true</tt>, so you can only use it if you know the answer!
46317 2009-12-08 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
46327 Moved to NAD Editorial. Rationale added below.
46332 <p><b>Rationale:</b></p>
46338 <p><b>Proposed resolution:</b></p>
46340 Change 30.6.6 [futures.unique_future]/3:
46344 The effect of calling any member function other than the
46345 destructor<ins>,</ins> or the move-assignment operator<ins>, or
46346 <tt>valid</tt>,</ins> on a <tt>future</tt> object for which <tt>valid()
46347 == false</tt> is undefined.
46356 <h3><a name="1274"></a>1274. <tt>atomic_future</tt> constructor</h3>
46357 <p><b>Section:</b> 30.6.8 [futures.atomic_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46358 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-22 <b>Last modified:</b> 2010-10-23</p>
46359 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.atomic_future">issues</a> in [futures.atomic_future].</p>
46360 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46361 <p><b>Discussion:</b></p>
46363 In 30.6.8 [futures.atomic_future] this constructor:
46366 <blockquote><pre>atomic_future(future<R>&&);
46367 </pre></blockquote>
46370 is declared in the synopsis, but not defined. Instead
46371 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.htm">n2997</a>
46375 <blockquote><pre>atomic_future(const future<R>&& rhs);
46376 </pre></blockquote>
46380 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">n3000</a>
46384 <blockquote><pre>atomic_future(atomic_future<R>&& rhs);
46385 </pre></blockquote>
46388 both of which are wrong. The constructor definition should be changed
46389 to match the synopsis.
46393 2009-12-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
46403 Moved to NAD Editorial. Rationale added below.
46408 <p><b>Rationale:</b></p>
46414 <p><b>Proposed resolution:</b></p>
46416 Adjust the signature above 30.6.8 [futures.atomic_future]/6 like so:
46419 <blockquote><pre>atomic_future(<del>atomic_</del>future<ins><R></ins>&& rhs);
46420 </pre></blockquote>
46427 <h3><a name="1275"></a>1275. creating and setting futures</h3>
46428 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46429 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-22 <b>Last modified:</b> 2010-10-23</p>
46430 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
46431 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46432 <p><b>Discussion:</b></p>
46434 30.6.6 [futures.unique_future]/1 should be updated to mention
46439 30.6.7 [futures.shared_future]/1 should also be updated for
46440 <tt>async</tt>. That paragraph also says
46444 ... Its value or exception can be set by use of a
46445 <tt>shared_future</tt>, <tt>promise</tt> (30.6.5 [futures.promise]), or <tt>packaged_task</tt> (30.6.10 [futures.task]) object that shares the same associated state.
46449 How can the value be set by a <tt>shared_future</tt>?
46453 30.6.8 [futures.atomic_future]/1 says
46457 An <tt>atomic_future</tt> object can only be created by use of a
46458 <tt>promise</tt> (30.6.5 [futures.promise]) or
46459 <tt>packaged_task</tt> (30.6.10 [futures.task]) object.
46463 which is wrong, it's created from a <tt>std::future</tt>, which could
46464 have been default-cosntructed. That paragraph should be closer to the
46465 text of 30.6.7 [futures.shared_future]/1, and should also mention
46470 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
46476 <p><b>Rationale:</b></p>
46479 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46483 <p><b>Proposed resolution:</b></p>
46490 <h3><a name="1281"></a>1281. CopyConstruction and Assignment between ratios having the same normalized form</h3>
46491 <p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
46492 <b>Submitter:</b> Vicente Juan Botet Escribá <b>Opened:</b> 2009-12-07 <b>Last modified:</b> 2010-11-24</p>
46493 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
46494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
46495 <p><b>Discussion:</b></p>
46497 CopyConstruction and Assignment between <tt>ratio</tt>s having the same
46498 normalized form. Current
46499 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
46500 do not allows to copy-construct or assign <tt>ratio</tt> instances of
46501 <tt>ratio</tt> classes having the same normalized form.
46505 Two <tt>ratio</tt> classes <tt>ratio<N1,D1></tt> and
46506 <tt>ratio<N2,D2></tt> have the same normalized form if
46509 <blockquote><pre>ratio<N1, D1>::num == ratio<N2, D2>::num &&
46510 ratio<N1, D1>::den == ratio<N2, D2>::den
46511 </pre></blockquote>
46514 This simple example
46517 <blockquote><pre>ratio<1,3> r1;
46518 ratio<3,9> r2;
46520 </pre></blockquote>
46523 fails to compile in (1). Other example
46526 <blockquote><pre>ratio<1,3> r1;
46527 ratio_subtract<ratio<2,3>, ratio<1,3>>::type r2;
46529 </pre></blockquote>
46532 The nested type of <tt>ratio_subtract<ratio<2,3>,
46533 ratio<1,3>></tt> could be <tt>ratio<3,9></tt> so the compilation
46534 could fail. It could also be <tt>ratio<1,3></tt> and the compilation
46539 In 20.6.2 [ratio.arithmetic] 3 and similar clauses
46543 3 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio<T1,
46544 T2></tt> where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num *
46545 R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
46549 the meaning of synonym let think that the result shall be a normalized
46550 <tt>ratio</tt> equivalent to <tt>ratio<T1, T2></tt>, but there is not an
46551 explicit definition of what synonym means in this context.
46555 Additionally we should add a typedef for accessing the normalized
46556 <tt>ratio</tt>, and change 20.6.2 [ratio.arithmetic] to return only this
46557 <em>normalized</em> result.
46567 There is no consensus to add the converting copy constructor or converting copy
46568 assignment operator. However there was consensus to add the typedef.
46572 Proposed wording modified. Original proposed wording preserved here. Moved to
46576 <blockquote class="note">
46578 Make <tt>ratio</tt> default constructible, copy-constructible and assignable
46579 from any <tt>ratio</tt> which has the same reduced form.
46583 Add to 20.6.1 [ratio.ratio] synopsis
46586 <blockquote><pre>template <intmax_t N, intmax_t D = 1>
46589 static constexpr intmax_t num;
46590 static constexpr intmax_t den;
46592 <ins>typedef ratio<num, den> type;</ins>
46594 <ins>ratio() = default;
46595 template <intmax_t N2, intmax_t D2>
46596 ratio(const ratio<N2, D2>&);
46597 template <intmax_t N2, intmax_t D2>
46598 ratio& operator=(const ratio<N2, D2>&);</ins>
46600 </pre></blockquote>
46603 Add to 20.6.1 [ratio.ratio]:
46608 Two ratio classes <tt>ratio<N1,D1></tt> and <tt>ratio<N2,D2></tt>
46609 have the same reduced form if <tt>ratio<N1,D1>::type</tt> is the same
46610 type as <tt>ratio<N2,D2>::type</tt>
46616 Add a new section: [ratio.cons]
46621 Construction and assignment [ratio.cons]
46624 <pre>template <intmax_t N2, intmax_t D2>
46625 ratio(const ratio<N2, D2>& r);
46630 <i>Effects:</i> Constructs a <tt>ratio</tt> object.
46633 <i>Remarks:</i> This constructor shall not participate in overload resolution
46634 unless <tt>r</tt> has the same reduced form as <tt>*this</tt>.
46638 <pre>template <intmax_t N2, intmax_t D2>
46639 ratio& operator=(const ratio<N2, D2>& r);
46644 <i>Effects:</i> None.
46647 <i>Returns:</i> <tt>*this</tt>.
46650 <i>Remarks:</i> This operator shall not participate in overload resolution
46651 unless <tt>r</tt> has the same reduced form as <tt>*this</tt>.
46658 Change 20.6.2 [ratio.arithmetic]
46663 Implementations may use other algorithms to compute these values. If overflow
46664 occurs, a diagnostic shall be issued.
46667 <pre>template <class R1, class R2> struct ratio_add {
46668 typedef <i>see below</i> type;
46673 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio<T1,
46674 T2><ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
46675 R2::den + R2::num * R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den *
46679 <pre>template <class R1, class R2> struct ratio_subtract {
46680 typedef <i>see below</i> type;
46685 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio<T1,
46686 T2><ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
46687 R2::den - R2::num * R1::den</tt> and <tt>T2</tt> has the value <tt>R1::den *
46691 <pre>template <class R1, class R2> struct ratio_multiply {
46692 typedef <i>see below</i> type;
46697 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio<T1,
46698 T2><ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
46699 R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
46702 <pre>template <class R1, class R2> struct ratio_divide {
46703 typedef <i>see below</i> type;
46708 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio<T1,
46709 T2><ins>::type</ins></tt> where <tt>T1</tt> has the value <tt>R1::num *
46710 R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
46720 2010-03-27 Howard adds:
46726 Daniel brought to my attention the recent addition of the typedef <tt>type</tt>
46728 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>:
46731 <blockquote><pre>typedef ratio type;
46732 </pre></blockquote>
46735 This issue was discussed in Pittsburgh, and the decision there was to accept the
46736 typedef as proposed and move to Review. Unfortunately the issue was accidently
46737 applied to the FCD, and incorrectly. The FCD version of the typedef refers to
46738 <tt>ratio<N, D></tt>, but the typedef is intended to refer to
46739 <tt>ratio<num, den></tt> which in general is not the same type.
46743 I've updated the wording to diff against
46744 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>.
46749 <p><i>[Batavia: NAD Editorial - see rationale below]</i></p>
46754 <p><b>Rationale:</b></p>Already fixed in working draft
46756 <p><b>Proposed resolution:</b></p>
46758 Add to 20.6.1 [ratio.ratio] synopsis
46761 <blockquote><pre>template <intmax_t N, intmax_t D = 1>
46764 static constexpr intmax_t num;
46765 static constexpr intmax_t den;
46767 typedef ratio<ins><num, den></ins> type;
46769 </pre></blockquote>
46777 <h3><a name="1282"></a>1282. A proposal to add std::split algorithm</h3>
46778 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
46779 <b>Submitter:</b> Igor Semenov <b>Opened:</b> 2009-12-07 <b>Last modified:</b> 2010-10-23</p>
46780 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
46781 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
46782 <p><b>Discussion:</b></p>
46787 Motivation and Scope
46790 Splitting strings into parts by some set of delimiters is an often task, but
46791 there is no simple and generalized solution in C++ Standard. Usually C++
46792 developers use <tt>std::basic_stringstream<></tt> to split string into
46793 parts, but there are several inconvenient restrictions:
46798 we cannot explicitly assign the set of delimiters;
46801 this approach is suitable only for strings, but not for other types of
46805 we have (possible) performance leak due to string instantiation.
46812 Impact on the Standard
46815 This algorithm doesn't interfere with any of current standard algorithms.
46824 This algorithm is implemented in terms of input/output iterators. Also, there is
46825 one additional wrapper for <tt>const CharType *</tt> specified delimiters.
46831 Example implementation
46833 <pre>template< class It, class DelimIt, class OutIt >
46834 void split( It begin, It end, DelimIt d_begin, DelimIt d_end, OutIt out )
46836 while ( begin != end )
46838 It it = std::find_first_of( begin, end, d_begin, d_end );
46839 *out++ = std::make_pair( begin, it );
46840 begin = std::find_first_of( it, end, d_begin, d_end,
46841 std::not2( std::equal_to< typename It::value_type >() ) );
46845 template< class It, class CharType, class OutIt >
46846 void split( It begin, It end, const CharType * delim, OutIt out )
46848 split( begin, end, delim, delim + std::strlen( delim ), out );
46857 <pre>std::string ss( "word1 word2 word3" );
46858 std::vector< std::pair< std::string::const_iterator, std::string::const_iterator > > v;
46859 split( ss.begin(), ss.end(), " ", std::back_inserter( v ) );
46861 for ( int i = 0; i < v.size(); ++i )
46863 std::cout << std::string( v[ i ].first, v[ i ].second ) << std::endl;
46874 2010-01-22 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
46875 Rationale added below.
46880 <p><b>Rationale:</b></p>
46882 The LWG is not considering completely new features for standardization at this
46883 time. We would like to revisit this good suggestion for a future TR and/or
46888 <p><b>Proposed resolution:</b></p>
46890 Add to the synopsis in 25.1 [algorithms.general]:
46893 <blockquote><pre>template< class ForwardIterator1, class ForwardIterator2, class OutputIterator >
46894 void split( ForwardIterator1 first, ForwardIterator1 last,
46895 ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
46896 OutputIterator result );
46898 template< class ForwardIterator1, class CharType, class OutputIterator >
46899 void split( ForwardIterator1 first, ForwardIterator1 last,
46900 const CharType * delimiters, OutputIterator result );
46901 </pre></blockquote>
46904 Add a new section [alg.split]:
46907 <blockquote><pre>template< class ForwardIterator1, class ForwardIterator2, class OutputIterator >
46908 void split( ForwardIterator1 first, ForwardIterator1 last,
46909 ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
46910 OutputIterator result );
46915 1. <i>Effects:</i> splits the range <tt>[first, last)</tt> into parts, using any
46916 element of <tt>[delimiter_first, delimiter_last)</tt> as a delimiter. Results
46917 are pushed to output iterator in the form of <tt>std::pair<ForwardIterator1,
46918 ForwardIterator1></tt>. Each of these pairs specifies a maximal subrange of
46919 <tt>[first, last)</tt> which does not contain a delimiter.
46922 2. <i>Returns:</i> nothing.
46925 3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
46929 <pre>template< class ForwardIterator1, class CharType, class OutputIterator >
46930 void split( ForwardIterator1 first, ForwardIterator1 last,
46931 const CharType * delimiters, OutputIterator result );
46936 1. <i>Effects:</i> split the range <tt>[first, last)</tt> into parts, using any
46937 element of <tt>delimiters</tt> (interpreted as zero-terminated string) as a
46938 delimiter. Results are pushed to output iterator in the form of
46939 <tt>std::pair<ForwardIterator1, ForwardIterator1></tt>. Each of these
46940 pairs specifies a maximal subrange of <tt>[first, last)</tt> which does not
46941 contain a delimiter.
46944 2. <i>Returns:</i> nothing.
46947 3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
46958 <h3><a name="1289"></a>1289. Generic casting requirements for smart pointers</h3>
46959 <p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
46960 <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2009-12-14 <b>Last modified:</b> 2010-11-24</p>
46961 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility">issues</a> in [utility].</p>
46962 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
46963 <p><b>Discussion:</b></p>
46965 In section 20.2.5 [allocator.requirements], Table 40
\97 Allocator requirements,
46966 the following expression is required for allocator pointers:
46971 <caption>Table 40
\97 Allocator requirements</caption>
46973 <th>Expression</th>
46974 <th>Return type</th>
46975 <th>Assertion/note<br>pre-/post-condition</th>
46979 <td><tt>static_cast<X::pointer>(w)</tt></td>
46980 <td><tt>X::pointer</tt></td>
46981 <td><tt>static_cast<X::pointer>(w) == p</tt></td>
46988 To achieve this expression, a smart pointer writer must introduce an explicit
46989 conversion operator from <tt>smart_ptr<void></tt> to
46990 <tt>smart_ptr<T></tt> so that
46991 <tt>static_cast<pointer>(void_ptr)</tt> is a valid expression.
46992 Unfortunately this explicit conversion weakens the safety of a smart pointer
46993 since the following expression (invalid for raw pointers) would become valid:
46996 <blockquote><pre>smart_ptr<void> smart_v = ...;
46997 smart_ptr<T> smart_t(smart_v);
46998 </pre></blockquote>
47001 On the other hand, <tt>shared_ptr</tt> also defines its own casting functions in
47002 20.9.10.2.10 [util.smartptr.shared.cast], and although it's unlikely that a
47003 programmer will use <tt>shared_ptr</tt> as <tt>allocator::pointer</tt>, having
47004 two different ways to do the same cast operation does not seem reasonable. A
47005 possible solution would be to replace <tt>static_cast<X::pointer>(w)</tt>
47006 expression with a user customizable (via ADL)
47007 <tt>static_pointer_cast<value_type>(w)</tt>, and establish the
47008 <tt>xxx_pointer_cast</tt> functions introduced by <tt>shared_ptr</tt> as the
47009 recommended generic casting utilities of the standard.
47013 Unfortunately, we've experienced problems in Boost when trying to establish
47014 <tt>xxx_pointer_cast</tt> as customization points for generic libraries (<a href="http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html">http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html</a>)
47015 because these casting functions are called with explicit template parameters and
47016 the standard says in 14.8.1 [temp.arg.explicit] p.8 "Explicit template
47017 argument specification":
47021 8 ...But when a function template with explicit template arguments is used, the
47022 call does not have the correct syntactic form unless there is a function
47023 template with that name visible at the point of the call. If no such name is
47024 visible, the call is not syntactically well-formed and argument-dependent lookup
47032 <blockquote><pre>template<class BasePtr>
47033 void generic_ptr_swap(BasePtr p)
47035 //ADL customization point
47039 </pre></blockquote>
47042 but not the following:
47045 <blockquote><pre>template<class BasePtr>
47046 void generic_ptr_algo(BasePtr p)
47048 typedef std::pointer_traits<BasePtr>::template
47049 rebind<Derived> DerivedPtr;
47050 DerivedPtr dp = static_pointer_cast<Derived>(p);
47052 </pre></blockquote>
47055 The solution to make <tt>static_pointer_cast</tt> a customization point is to
47056 add a generic declaration (no definition) of <tt>static_pointer_cast</tt> in a
47057 namespace (like <tt>std</tt>) and apply "<tt>using
47058 std::static_pointer_cast</tt>" declaration to activate ADL:
47061 <blockquote><pre>namespace std{
47063 template<typename U, typename T>
47065 static_pointer_cast(T&&) = delete;
47069 template<class BasePtr>
47070 void generic_ptr_algo(BasePtr p)
47072 typedef std::pointer_traits<BasePtr>::template
47073 rebind<Derived> DerivedPtr;
47075 //ADL applies because static_pointer_cast is made
47076 // visible according to [temp.arg.explicit]/8
47077 using std::static_pointer_cast;
47079 DerivedPtr dp = static_pointer_cast<Derived>(p);
47083 </pre></blockquote>
47086 A complete solution will need also the definition of
47087 <tt>static_pointer_cast</tt> for raw pointers, and this definition has been
47088 present in Boost (<a href="http://www.boost.org/boost/pointer_cast.hpp">http://www.boost.org/boost/
47089 pointer_cast.hpp</a>) for years.
47093 2010-03-26 Daniel made editorial adjustments to the proposed wording.
47098 Moved to NAD Future at 2010-11 Batavia
47102 This is a new feature rather than a defect.
47103 It can be added later: "this is such a hairy area that people will put up with changes"
47108 <p><b>Proposed resolution:</b></p>
47110 Add to section 20.3 [utility] Utility components, Header
47111 <tt><utility></tt> synopsis:
47114 <blockquote><pre>// 20.3.X, generic pointer cast functions
47116 template<typename U, typename T>
47118 static_pointer_cast(T&&) = delete;
47120 template<typename U, typename T>
47122 dynamic_pointer_cast(T&&) = delete;
47124 template<typename U, typename T>
47126 const_pointer_cast(T&&) = delete;
47128 //Overloads for raw pointers
47129 template<typename U, typename T>
47130 auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));
47132 template<typename U, typename T>
47133 auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));
47135 template<typename U, typename T>
47136 auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));
47137 </pre></blockquote>
47140 Add to section 20.3 [utility] Utility components, a new subclause
47141 20.3.X Pointer cast utilities [pointer.cast]:
47146 20.3.X Pointer cast utilities [pointer.cast]
47150 1 The library defines generic pointer casting function templates so that template code
47151 can explicitly make these names visible and activate argument-dependent lookup
47152 for pointer cast calls.
47155 <pre>//Generic declarations
47156 template<typename U, typename T>
47158 static_pointer_cast(T&&) = delete;
47160 template<typename U, typename T>
47162 dynamic_pointer_cast(T&&) = delete;
47164 template<typename U, typename T>
47166 const_pointer_cast(T&&) = delete;
47170 2 The library also defines overloads of these functions for raw pointers.
47173 <pre>//Overloads for raw pointers
47174 template<typename U, typename T>
47175 auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));
47179 <i>Returns:</i> <tt>static_cast<U*>(t)</tt>
47182 <pre>template<typename U, typename T>
47183 auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));
47187 <i>Returns:</i> <tt>dynamic_cast<U*>(t)</tt>
47190 <pre>template<typename U, typename T>
47191 auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));
47195 <i>Returns:</i> <tt>const_cast<U*>(t)</tt>
47202 <blockquote><pre>#include <utility> //static_pointer_cast
47203 #include <memory> //pointer_traits
47206 class Derived : public Base{};
47208 template<class BasePtr>
47209 void generic_pointer_code(BasePtr b)
47211 typedef std::pointer_traits<BasePtr>::template
47212 rebind<Derived> DerivedPtr;
47214 using std::static_pointer_cast;
47215 //ADL applies now that static_pointer_cast is visible
47216 DerivedPtr d = static_pointer_cast<Derived>(b);
47218 </pre></blockquote>
47221 \97 <i>end example</i>]
47227 Replace in section 20.2.5 [allocator.requirements] Table 40
\97 Allocator
47228 requirements, the following table entries for allocator pointers:
47233 <caption>Table 40
\97 Allocator requirements</caption>
47235 <th>Expression</th>
47236 <th>Return type</th>
47237 <th>Assertion/note<br>pre-/post-condition</th>
47242 <td><tt>static<ins>_pointer</ins>_cast<<del>X::pointer</del><ins>T</ins>>(w)</tt></td>
47243 <td><tt>X::pointer</tt></td>
47244 <td><tt>static<ins>_pointer</ins>_cast<<del>X::pointer</del><ins>T</ins>>(w) == p</tt></td>
47249 <td><tt>static<ins>_pointer</ins>_cast<<del>X::const_pointer</del><ins>const T</ins>>(w)</tt></td>
47250 <td><tt>X::const_pointer</tt></td>
47251 <td><tt>static<ins>_pointer</ins>_cast<<del>X::const_pointer</del><ins>const T</ins>>(z) == q</tt></td>
47264 <h3><a name="1291"></a>1291. exceptions thrown during <tt>promise::set_value</tt></h3>
47265 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
47266 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-18 <b>Last modified:</b> 2010-10-23</p>
47267 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
47268 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
47269 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
47270 <p><b>Discussion:</b></p>
47272 In 30.6.5 [futures.promise]
47276 Does <tt>promise<R>::set_value</tt> return normally if the copy/move
47277 constructor of <tt>R</tt> throws?
47281 The exception could be caught and set using
47282 <tt>promise<R>::set_exception</tt>, or it could be allowed to leave the
47283 <tt>set_value</tt> call, but it's not clear which is intended. I suggest the
47284 exception should not be caught.
47288 N.B. This doesn't apply to <tt>promise<R&>::set_value</tt> or
47289 <tt>promise<void>::set_value</tt> because they don't construct a new
47294 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
47300 <p><b>Rationale:</b></p>
47303 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
47307 <p><b>Proposed resolution:</b></p>
47309 Change 30.6.5 [futures.promise]/18:
47313 18 <i>Throws:</i> <tt>future_error</tt> if its associated state is already
47314 ready<ins> or, for the first version an exception thrown by the copy constructor
47315 of <tt>R</tt>, or for the second version an exception thrown by the move
47316 constructor of <tt>R</tt></ins>.
47324 <h3><a name="1296"></a>1296. <tt>map</tt> and <tt>multimap value_compare</tt> overspecified</h3>
47325 <p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
47326 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-12-22 <b>Last modified:</b> 2010-10-23</p>
47327 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
47328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
47329 <p><b>Discussion:</b></p>
47331 The container class templates <tt>map</tt> and <tt>multimap</tt> both contain a
47332 nested type called <tt>value_compare</tt>, that is used to compare the
47333 <tt>value_type pair</tt> elements, an adaptor of the user-supplied comparison
47334 function-like object.
47338 I believe these types are over-specified, as we require a distinct type for each
47339 template, even though the allocator plays no part in the comparator, and
47340 <tt>map</tt> and <tt>multimap value_compare</tt> classes could easily be shared.
47341 The benefits are similar to the SCARY iterator proposal (although on a much
47342 smaller scale!) but unlike SCARY, this is not a QoI issue today but actively
47347 If the <tt>value_compare</tt> classes were marked 'exposition only', a vendor
47348 would be free to experiment with implementations that do not produce so many
47349 template instantiations with negligible impact on conforming programs. (There
47350 is a minor risk that programs could no longer portably overload functions taking
47351 <tt>value_compare</tt> types. This scenario is extremely unlikely outside
47352 conformance suites.)
47356 (Note that there are no similar problems for unordered maps, nor any of the set
47361 2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
47362 Rationale added below.
47366 <p><b>Rationale:</b></p>
47368 The <tt>value_compare</tt> specification is an unfortunate bit from the past
47369 that we have to live with. Fortunately vendors can work around the problems
47370 mentioned in this issue.
47376 <p><b>Proposed resolution:</b></p>
47379 Above the declaration of class <tt>value_compare</tt> in the map synopsis, add:
47382 <blockquote><pre>template <class Key, class T, class Compare = less<Key>,
47383 class Allocator = allocator<pair<const Key, T> > >
47388 <ins>// exposition only.</ins>
47389 class value_compare
47390 : public binary_function<value_type,value_type,bool> {
47392 </pre></blockquote>
47397 p2 23.6.2 [multimap]:
47398 Above the declaration of class <tt>value_compare</tt> in the map synopsis, add:
47401 <blockquote><pre>template <class Key, class T, class Compare = less<Key>,
47402 class Allocator = allocator<pair<const Key, T> > >
47407 <ins>// exposition only.</ins>
47408 class value_compare
47409 : public binary_function<value_type,value_type,bool> {
47411 </pre></blockquote>
47418 <h3><a name="1300"></a>1300. circular definition of <tt>promise::swap</tt></h3>
47419 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
47420 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-26 <b>Last modified:</b> 2010-10-23</p>
47421 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
47422 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
47423 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
47424 <p><b>Discussion:</b></p>
47426 30.6.5 [futures.promise]/12 defines the effects of
47427 <tt>promise::swap(promise&)</tt> as
47430 <blockquote><pre>void swap(promise& other);
47433 12 <i>Effects:</i> <tt>swap(*this, other)</tt>
47438 and 30.6.5 [futures.promise]/25 defines <tt>swap(promise<R&>,
47439 promise<R>&)</tt> as
47442 <blockquote><pre>template <class R>
47443 void swap(promise<R>& x, promise<R>& y);
47446 25 <i>Effects:</i> <tt>x.swap(y)</tt>.
47451 2010-01-13 Daniel added "Throws: Nothing."
47456 2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47466 Moved to NAD Editorial. Rationale added below.
47471 <p><b>Rationale:</b></p>
47477 <p><b>Proposed resolution:</b></p>
47479 Change 30.6.5 [futures.promise] paragraph 12
47482 <blockquote><pre>void swap(promise& other);
47486 12 <i>Effects:</i> <del><tt>swap(*this, other)</tt></del> <ins>Exchanges the
47488 states of <tt>*this</tt> and <tt>other</tt>.</ins>
47494 <i>Throws:</i> Nothing.
47505 <h3><a name="1301"></a>1301. <tt>clear()</tt> and assignment</h3>
47506 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
47507 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-01-01 <b>Last modified:</b> 2010-10-23</p>
47508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
47509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
47510 <p><b>Discussion:</b></p>
47512 I propose that <tt>clear()</tt> be defined to be equivalent to
47513 <tt>erase(begin(),end())</tt> except not using copy or move of elements.
47518 To: C++ libraries mailing list<br>
47519 Message c++std-lib-26465
47523 and specifiying as post: <tt>size()==0</tt> might also not be appropriate
47524 because forward-Lists provide no <tt>size()</tt>, this it should be:
47525 post: <tt>empty()==true</tt>
47529 Bjarne Stroustrup schrieb/wrote:
47534 To: C++ libraries mailing list<br>
47535 Message c++std-lib-26458
47539 in table 94 we define <tt>clear()</tt> as:
47542 <blockquote><pre>a.clear() void erase(begin(), end())
47544 </pre></blockquote>
47547 Now <tt>erase</tt> requires assignment (<tt>MoveAssignable</tt>) which makes
47548 sense if we have to move an element, but why should that be required from
47549 <tt>clear()</tt> where all elements are destroyed?
47555 2010-01-23 Alisdiar provides wording.
47560 2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47565 2010-01-30 Daniel opens:
47571 First, I read the newly proposed spec for <tt>clear()</tt> that it does in
47572 general <em>not</em> invalidate a previous past-the-end iterator value, but
47573 <tt>deque</tt> says in 23.3.2.3 [deque.modifiers] for the semantics of
47574 <tt>erase</tt> that erasures at the end will invalidate the past-the-end
47575 iterator. With removal of a direct binding between <tt>clear()</tt> and
47576 <tt>erase()</tt> there seem to be some fixes necessary. One way to fix that
47577 would be to mention in Table 94 that this "may also invalidate the past-the-end
47578 iterator" and then to mention for all specific containers where this does not
47579 happen, the exception, [1] e.g. in <tt>std::vector</tt>. <tt>std::vector</tt>
47580 has no own specification of <tt>clear()</tt> and one aspect of the closed issue
47581 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a> was to realize just that (indirectly via <tt>erase</tt>). IMO
47582 we should now add an extra specification for <tt>clear()</tt>. Btw.:
47583 <tt>std::vector::erase</tt> reads to me that it would invalidate previous
47584 past-the-end values (and that seems correct in general).
47587 Before I will provide explicit wording, I would like to
47588 discuss these points.
47592 [1] <tt>std::list</tt> does fortunately specify that clear does not invalidate
47593 the past-the-end iterator.
47598 2010-02-08 Moved to Tentatively NAD Editorial after 5 positive votes on c++std-lib.
47599 Rationale added below.
47605 <p><b>Rationale:</b></p>
47607 Solved as proposed by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>.
47611 <p><b>Proposed resolution:</b></p>
47614 Change 23.2.1 [container.requirements.general]/10:
47619 Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.2.3, and 23.3.6.4) all
47620 container types defined in this Clause meet the following additional
47630 no <tt>erase()</tt>, <ins><tt>clear()</tt>,</ins> <tt>pop_back()</tt> or
47631 <tt>pop_front()</tt> function throws an exception.
47642 Replace the following words from Table 94
\97 Sequence container
47643 requirements (in addition to container) in 23.2.3 [sequence.reqmts]:
47648 <caption>Table 94
\97 Sequence container requirements (in addition to
47649 container)</caption>
47651 <th>Expression</th>
47652 <th>Return type</th>
47653 <th>Assertion/note<br>pre-/post-condition</th>
47657 <td><tt>a.clear()</tt></td>
47658 <td><tt>void</tt></td>
47659 <td><del><tt>erase(begin(), end())</tt></del><br>
47660 <ins>Destroys all elements in the container a. Invalidates all references,
47661 pointers, and iterators referring to the elements of <tt>a</tt> and may
47662 invalidate the past-the-end iterator.</ins><br>
47663 post: <tt><del>size() == 0</del> <ins>a.empty() == true</ins></tt>. </td>
47669 Add a new paragraph after 23.3.3.4 [forwardlist.modifiers]/23:
47672 <blockquote><pre>void clear();
47677 23 <i>Effects:</i> Erases all elements in the range <tt>[begin(),end())</tt>.
47680 <i>Remarks:</i> Does not invalidate past-the-end iterators.
47691 <h3><a name="1302"></a>1302. different <tt>emplace</tt> semantics for sequence and associated containers</h3>
47692 <p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
47693 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-01-03 <b>Last modified:</b> 2010-10-23</p>
47694 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
47695 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
47696 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
47697 <p><b>Discussion:</b></p>
47699 According to the new naming scheme introduced with
47700 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680</a>
47703 <blockquote><pre>vector<T> v;
47704 v.emplace(v.begin(),x,y,z)
47705 </pre></blockquote>
47708 now has a different semantics than
47711 <blockquote><pre>set<T> s;
47712 s.emplace(s.begin(),x,y,z);
47713 </pre></blockquote>
47716 While the version for <tt>vector</tt>s takes the first argument as position and
47717 the remaining for construction, the version for <tt>set</tt>s takes all
47718 arguments for construction.
47722 IMO, this is a serious design mistake for a couple of reasons:
47728 First, in principle, all STL member functions should have the same behavior with
47729 the same member function to avoid confusion and allow to write proper generic
47733 In fact, when I write the following simple function template:
47735 <blockquote><pre>template <typename T>
47736 void doEmplace (T& cont)
47738 cont.emplace(cont.begin(),"nico","josuttis",42);
47740 </pre></blockquote>
47742 the semantics depends on the type of the container.
47747 In addition, I also guess using the name <tt>emplace_hint()</tt> instead of
47748 <tt>emplace()</tt> for associative containers is a design mistake. According to
47749 my knowledge, it was a design goal of the original STL to provide ONE
47750 <tt>insert</tt> function, which works for ALL containers. This was
47751 <tt>insert(pos,val)</tt>.
47754 The trick to declare <tt>pos</tt> as a hint, allowed that we could implement a
47755 generic <tt>insert</tt> for all containers. Now, with the new <tt>emplace</tt>
47756 naming scheme, this trick is gone for the new kind of insertion.
47762 I consider this to be a serious design penalty because once this
47763 is specified we can't fix that without breaking backward compatibility.
47767 However, we have two choices for a fix:
47772 rename <tt>emplace_hint(pos,val)</tt> for associative containers back to
47773 <tt>emplace(pos,val)</tt>. However to avoid the overloading problems, we also
47774 have to rename the existing <tt>emplace(val)</tt> functions to something else (I
47775 don't have a good name here at hand).
47778 Keep <tt>emplace(val)</tt> for associative containers as it is, but rename
47779 <tt>emplace(pos,val)</tt> for sequence containers and
47780 <tt>emplace_hint(pos,val)</tt> to something like <tt>emplace_at(pos,val)</tt>,
47781 declaring that <tt>pos</tt> is a hint for associative containers.
47786 2010 Pittsburgh: Moved to NAD, rationale added below.
47792 <p><b>Rationale:</b></p>
47794 There was no consensus to make this change.
47798 <p><b>Proposed resolution:</b></p>
47799 <p> In 23.2.5 [unord.req], change: </p>
47802 <caption>Table 96
\97 Associative container requirements (in addition to
47803 container)</caption>
47805 <th>expression</th>
47806 <th>Return type</th>
47807 <th>Assertion/note pre-/post-condition</th>
47808 <th>Post-condition</th>
47811 <td colspan="4">...</td>
47814 <td><tt>a_uniq.emplace<ins>_value</ins>(args)</tt></td>
47815 <td><tt>pair<iterator, bool></tt></td>
47816 <td>inserts a T object t constructed with std::forward<Args>(args)...<br>
47817 if and only if there is no element in the container with key equivalent
47818 to the key of t.<br>
47819 The bool component of the returned pair is true if and only if the insertion
47820 takes place, and the iterator component of the pair points to the element
47821 with key equivalent to the key of t.</td>
47822 <td>logarithmic</td>
47825 <td><tt>a_eq.emplace<ins>_value</ins>(args)</tt></td>
47826 <td><tt>iterator</tt></td>
47827 <td>inserts a T object t constructed with std::forward<Args>(args)...
47828 and returns the iterator pointing to the newly inserted element.</td>
47829 <td>logarithmic</td>
47832 <td><tt>a.emplace<del>_hint</del>(p,args)</tt></td>
47833 <td><tt>iterator</tt></td>
47835 <tt>a.emplace<ins>_value</ins>(std::forward<Args>(args)...)</tt>.
47836 Return value is an iterator pointing to the element with the key
47837 equivalent to the newly inserted element. The const_iterator p is a hint
47838 pointing to where the search should start. Implementations are permitted
47839 to ignore the hint.</td> <td>logarithmic in general, but amortized
47840 constant if the element is inserted right after p</td>
47843 <td colspan="4">... </td>
47848 <p> In 23.2.5 [unord.req], change: </p>
47851 <caption>Table 98
\97 Unordered associative container requirements (in
47852 addition to container)</caption>
47854 <th>expression</th>
47855 <th>Return type</th>
47856 <th>Assertion/note pre-/post-condition</th>
47857 <th>Post-condition</th>
47860 <td colspan="4">...</td>
47863 <td><tt>a_uniq.emplace<ins>_value</ins>(args)</tt></td>
47864 <td><tt>pair<iterator, bool></tt></td>
47865 <td>inserts a <tt>T</tt> object <tt>t</tt> constructed with <tt>std::forward<Args>(args)...</tt> if
47866 and only if there is no element in the container with key equivalent to
47867 the key of <tt>t</tt>. The bool component of the returned pair is true if and only
47868 if the insertion takes place, and the iterator component of the pair points
47869 to the element with key equivalent to the key of t.</td>
47870 <td>Average case O(1), worst case O(a_uniq.size()).</td>
47873 <td><tt>a_eq.emplace<ins>_value</ins>(args)</tt></td>
47874 <td><tt>iterator</tt></td>
47875 <td>inserts a T object t constructed with std::forward<Args>(args)...
47876 and returns the iterator pointing to the newly inserted element.</td>
47877 <td>Average case O(1), worst case O(a_eq.size()).</td>
47880 <td><tt>a.emplace<del>_hint</del>(p,args)</tt></td>
47881 <td><tt>iterator</tt></td>
47883 <tt>a.emplace<ins>_value</ins>(std::forward<Args>(args)...)</tt>.
47884 Return value is an iterator pointing to the element with the key
47885 equivalent to the newly inserted element. The const_iterator p is a hint
47886 pointing to where the search should start. Implementations are permitted
47887 to ignore the hint.</td> <td>Average case O(1), worst case
47891 <td colspan="4">... </td>
47897 In 23.6.1 [map], 23.6.3 [set], 23.7.1 [unord.map], 23.7.3 [unord.set], change:
47900 <p><i>// modifiers:</i><br>
47901 <tt>template <class... Args> pair<iterator, bool> emplace<ins>_value</ins>(Args&&...
47903 template <class... Args> iterator emplace<del>_hint</del>(const_iterator
47904 position, Args&&... args);</tt></p>
47908 In 23.6.2 [multimap], 23.6.4 [multiset], 23.7.2 [unord.multimap], 23.7.4 [unord.multiset], change:
47911 <p><i>// modifiers:<br></i><tt>template <class... Args> iterator emplace<ins>_value</ins>(Args&&...
47913 template <class... Args> iterator emplace<del>_hint</del>(const_iterator position,
47914 Args&&... args);<br>
47923 <h3><a name="1304"></a>1304. missing preconditions for <tt>shared_future</tt></h3>
47924 <p><b>Section:</b> 30.6.7 [futures.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
47925 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-01-23 <b>Last modified:</b> 2010-10-23</p>
47926 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.shared_future">issues</a> in [futures.shared_future].</p>
47927 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
47928 <p><b>Discussion:</b></p>
47931 The revised futures package in the current working paper simplified the
47932 <tt>is_ready/has_exception/has_value</tt> set of APIs, replacing them with a
47933 single 'valid' method. This method is used in many places to signal pre- and
47934 post- conditions, but that edit is not complete. Each method on a
47935 <tt>shared_future</tt> that requires an associated state should have a
47936 pre-condition that <tt>valid() == true</tt>.
47940 2010-01-28 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47950 Moved to NAD Editorial. Rationale added below.
47955 <p><b>Rationale:</b></p>
47961 <p><b>Proposed resolution:</b></p>
47963 Insert the following extra paragraphs:
47967 In 30.6.7 [futures.shared_future]
47970 <blockquote><pre>shared_future();
47974 4 <i>Effects:</i> constructs ...
47978 <i>Postcondition:</i> <tt>valid() == false</tt>.
47982 <i>Throws:</i> nothing.
47987 <blockquote><pre>void wait() const;
47992 <i>Requires:</i> <tt>valid() == true</tt>.
47996 22 <i>Effects:</i> if the associated ...
48001 <blockquote><pre>template <class Rep, class Period>
48002 bool wait_for(const chrono::duration<Rep, Period>& rel_time) const;
48007 <i>Requires:</i> <tt>valid() == true</tt>.
48011 23 <i>Effects:</i> if the associated ...
48016 <blockquote><pre>template <class Clock, class Duration>
48017 bool wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
48022 <i>Requires:</i> <tt>valid() == true</tt>.
48026 25 <i>Effects:</i> blocks until ...
48037 <h3><a name="1305"></a>1305. preconditions for <tt>atomic_future</tt></h3>
48038 <p><b>Section:</b> 30.6.8 [futures.atomic_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
48039 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-01-23 <b>Last modified:</b> 2010-10-23</p>
48040 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.atomic_future">issues</a> in [futures.atomic_future].</p>
48041 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
48042 <p><b>Discussion:</b></p>
48045 The revised futures package in the current working paper simplified the
48046 <tt>is_ready/has_exception/has_value</tt> set of APIs, replacing them with a
48047 single 'valid' method. This method is used in many places to signal pre- and
48048 post- conditions, but that edit is not complete.
48052 Atomic future retains the extended earlier API, and provides defined,
48053 synchronized behaviour for all calls. However, some preconditions and throws
48054 clauses are missing, which can easily be built around the new <tt>valid()</tt>
48055 api. Note that for consistency, I suggest <tt>is_ready/has_exception/has_value
48056 throw</tt> an exception if <tt>valid()</tt> is not <tt>true</tt>, rather than
48057 return <tt>false</tt>. I think this is implied by the existing pre-condition on
48062 2010-01-23 See discussion starting with Message c++std-lib-26666.
48067 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
48073 <p><b>Rationale:</b></p>
48076 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
48080 <p><b>Proposed resolution:</b></p>
48082 Insert the following extra paragraphs:
48086 In 30.6.8 [futures.atomic_future]
48089 <blockquote><pre>bool is_ready() const;
48093 17 <i><del>Precondition</del> <ins>Requires</ins>:</i> <tt>valid() == true</tt>.
48097 18 <i>Returns:</i> <tt>true</tt> only if the associated state is ready.
48101 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48102 <tt>no_state</tt> if the precondition is not met.
48108 <blockquote><pre>bool has_exception() const;
48113 <i>Requires:</i> <tt>valid() == true</tt>.
48117 19 <i>Returns:</i> <tt>true</tt> only if the associated state is ready and
48118 contains an exception.
48122 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48123 <tt>no_state</tt> if the precondition is not met.
48129 <blockquote><pre>bool has_value() const;
48134 <i>Requires:</i> <tt>valid() == true</tt>.
48138 20 <i>Returns:</i> <tt>true</tt> only if the associated state is ready and
48143 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48144 <tt>no_state</tt> if the precondition is not met.
48150 <blockquote><pre>void wait() const;
48155 <i>Requires:</i> <tt>valid() == true</tt>.
48159 22 <i>Effects:</i> blocks until ...
48163 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48164 <tt>no_state</tt> if the precondition is not met.
48170 <blockquote><pre>template <class Rep, class Period>
48171 bool wait_for(const chrono::duration<Rep, Period>& rel_time) const;
48176 <i>Requires:</i> <tt>valid() == true</tt>.
48180 23 <i>Effects:</i> blocks until ...
48184 24 <i>Returns:</i> <tt>true</tt> only if ...
48188 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48189 <tt>no_state</tt> if the precondition is not met.
48195 <blockquote><pre>template <class Clock, class Duration>
48196 bool wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
48201 <i>Requires:</i> <tt>valid() == true</tt>.
48205 25 <i>Effects:</i> blocks until ...
48209 26 <i>Returns:</i> <tt>true</tt> only if ...
48213 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48214 <tt>no_state</tt> if the precondition is not met.
48226 <h3><a name="1308"></a>1308. Concerns about <tt>initializer_list</tt> overloads of <tt>min</tt>,
48227 <tt>max</tt>, and <tt>minmax</tt></h3>
48228 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
48229 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2010-02-02 <b>Last modified:</b> 2010-10-23</p>
48230 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
48231 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
48232 <p><b>Discussion:</b></p>
48234 In San Francisco, June 2008, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2722.pdf">N2722</a>
48235 was adopted, replacing the variadic templates <tt>min</tt>, <tt>max</tt>, and
48236 <tt>minmax</tt> by overloads that have an <tt>initializer_list<T></tt>
48237 parameter. The paper showed benchmark results wherein <tt>initializer_list</tt>
48238 versions of <tt>min</tt> appeared to outperform the corresponding variadic
48239 template. Unfortunately, in October 2009 a very serious error was detected in
48240 the benchmark. (<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=25210">c++std-lib-25210</a>).
48241 In fact, an <tt>initializer_list<T></tt> version of <tt>min</tt> often
48242 appears to perform <i>worse</i> than the corresponding variadic template,
48243 especially when <tt>T</tt> has an expensive copy constructor (<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=25253">c++std-lib-25253</a>,
48244 <a href="http://www.xs4all.nl/~nd/dekkerware/issues/n2772_fix">http://www.xs4all.nl/~nd/dekkerware/issues/n2772_fix</a>).
48247 IMO, the biggest problem of the <tt>initializer_list</tt> overloads is that they
48248 pass and return <tt>T</tt> objects <i>by value</i>. Which has the following
48254 They require that <tt>T</tt> is CopyConstructible. IMO that is too much of a
48255 constraint for a generic, general purpose function like
48256 <tt>std::min<T></tt>.
48259 They potentially throw an exception, even if <tt>T</tt>'s less-than-operator
48260 throws nothing. (And of course, less-than typically throws nothing.)
48263 They are inconsistent with C++03 std::<tt>min</tt> and std::<tt>max</tt>.
48264 Consider the subtle difference between <tt>const T& c1 = min(a,b);</tt> and
48265 <tt>const T& c2 = min({a,b});</tt> (<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=25265">c++std-lib-25265</a>)
48268 They do not conveniently support use cases that need to have a reference to the
48269 minimum or maximum object <i>itself</i>, rather than just a copy.
48272 They potentially perform badly: possibly <i>O(n)</i>, when the arguments
48273 themselves have a size of <i>n</i>.
48278 In the future, this problem might be solvable by using an
48279 <tt>initializer_list</tt> of <i>const references</i>, instead:
48281 <blockquote><pre>const T& min(initializer_list<const T&>);
48282 const T& max(initializer_list<const T&>);
48283 pair<const T&, const T&> minmax(initializer_list<const T&>);
48284 </pre></blockquote>
48287 It is unlikely that C++0x will support <tt>initializer_list<const
48288 T&></tt>, but technically it seems possible to add such a language
48289 feature after C++0x (<a href="http://accu.org/cgi-bin/wg21/message?wg=core&msg=15428">c++std-core-15428</a>).
48292 Variadic templates of <tt>min</tt>, <tt>max</tt>, and <tt>minmax</tt>, as
48293 proposed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2551.pdf">N2551</a>
48294 (Sylvain Pion), do have some other advantages over <tt>initializer_list</tt>
48299 It is likely that those variadic templates can be declared <tt>constexpr</tt>,
48300 now that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3006.html#991">
48301 CWG issue #991</a> is in drafting status.
48304 They provide complete compile-time protection against accidentally passing zero
48310 Unfortunately, the variadic templates of <tt>min</tt>, <tt>max</tt>, and
48311 <tt>minmax</tt> may still need further improvement, before having them in the
48312 Standard Library. Especially the optional <tt>Compare</tt> parameter appears to
48313 be a concern. So for this moment I recommend to keep both versions out of C++0x,
48314 and postpone further discussion until after C++0x.
48318 2010 Pittsburgh: Discussed and the LWG still prefers the initializer list
48320 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>.
48326 <p><b>Rationale:</b></p>
48327 We prefer the solution of
48328 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
48329 which will be reapplied.
48332 <p><b>Proposed resolution:</b></p>
48334 Remove both variadic templates and <tt>initializer_list</tt> overloads of
48335 <tt>min</tt>, <tt>max</tt>, and <tt>minmax</tt> from the synopsis in
48336 25.1 [algorithms.general] and from 25.4.7 [alg.min.max].
48341 Note: This proposed resolution will resolve LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a> as NAD.
48351 <h3><a name="1311"></a>1311. multi-pass property of Forward Iterator underspecified</h3>
48352 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
48353 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-07 <b>Last modified:</b> 2010-10-23</p>
48354 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
48355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
48356 <p><b>Discussion:</b></p>
48358 The following example demonstrates code that would meet the guarantees of a
48359 Forward Iterator, but only permits a single traversal of the underlying
48363 <blockquote><pre>template< typename ForwardIterator>
48364 struct bad_iterator {
48365 shared_ptr<ForwardIterator> impl;
48367 bad_iterator( ForwardIterator iter ) {
48368 : impl{new ForwardIterator{iter} }
48372 auto operator*() const -> decltype(*ForwardIterator{}) {
48376 auto operator->() const -> ForwardIterator {
48380 auto operator==(bad_iterator const & rhs) {
48381 return impl == rhs.impl;
48384 auto operator++() {
48387 // other operations as necessary...
48389 </pre></blockquote>
48392 Here, we use <tt>shared_ptr</tt> to wrap a forward iterator, so all iterators
48393 constructed from the same original iterator share the same 'value', and
48394 incrementing any one copy increments all others.
48398 There is a missing guarantee, expressed by the following code sequence
48401 <blockquote><pre>FwdIter x = seq.begin(); // obtain forward iterator from a sequence
48402 FwdIter y = x; // copy the iterator
48403 assert(x == y); // iterators must be the same
48404 ++x; // increment *just one* iterator
48405 assert(x != y); // iterators *must now be different*
48406 ++y; // increment the other iterator
48407 assert(x == y); // now the iterators must be the same again
48408 </pre></blockquote>
48411 That inequality in the middle is an essential guarantee. Note that this list is
48412 simplified, as each assertion should also note that they refer to exactly the
48413 same element <tt>(&*x == &*y)</tt> but I am not complicating the issue
48414 with tests to support proxy iterators, or value types overloading unary
48415 <tt>operator+</tt>.
48419 I have not yet found a perverse example that can meet this additional
48420 constraint, and not meet the multi-pass expectations of a Forward Iterator
48421 without also violating other Forward Iterator requirements.
48425 Note that I do not yet have standard-ready wording to resolve the problem, as
48426 saying this neatly and succinctly in 'standardese' is more difficult.
48430 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
48436 <p><b>Rationale:</b></p>
48439 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
48443 <p><b>Proposed resolution:</b></p>
48450 <h3><a name="1313"></a>1313. Seed sequence's param function not useful for pure output iterator</h3>
48451 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
48452 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-02-07 <b>Last modified:</b> 2010-10-23</p>
48453 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
48454 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
48455 <p><b>Discussion:</b></p>
48457 The Seed sequence requirements (26.5.1.2 [rand.req.seedseq]) require the
48458 existence of a member function
48461 <blockquote><pre>template<typename OutputIterator>
48462 void param(OutputIterator ob);
48463 </pre></blockquote>
48466 The fact that this function returns <tt>void</tt> instead of the value of
48467 <tt>ob</tt> after accepting the sequence data leads to the same problem as in
48468 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a> - In case of pure output iterators there is no way to
48469 serialize further data into that data sink.
48473 2010-02-07 Howard adds:
48478 At the time this issue was opened, the suggested changes are with respect to an
48479 anticipated draft which does not yet exist.
48488 No technical counterarguments, but it is simply too late in the process
48489 to make this change at this point.
48493 <p><b>Proposed resolution:</b></p>
48497 In Table 109
\97 Seed sequence requirements, expression "<tt>r.param(ob)</tt>"
48502 <blockquote><pre><del>void</del><ins>OutputIterator</ins>
48503 </pre></blockquote>
48508 In 26.5.7.1 [rand.util.seedseq], class seed_seq synopsis change
48511 <blockquote><pre>template<class OutputIterator>
48512 <del>void</del><ins>OutputIterator</ins> param(OutputIterator dest) const;
48513 </pre></blockquote>
48524 <h3><a name="1314"></a>1314. <tt>NULL</tt> and <tt>nullptr</tt></h3>
48525 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
48526 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2010-02-07 <b>Last modified:</b> 2010-10-23</p>
48527 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
48528 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
48529 <p><b>Discussion:</b></p>
48531 Currently, the 18.2 [support.types]/3 allows <tt>NULL</tt> to be any
48532 null pointer constant. The footnote marks that 0 or 0L might be appropriate.
48533 However, this definition also allows the implementation to define <tt>NULL</tt>
48534 to be <tt>nullptr</tt>. This may lead to overload and conversion issues more
48535 serious than with the C++98 version:
48538 <blockquote><pre>void f(void*);
48543 // calls f(int) if NULL is integral
48544 // calls f(void*) if NULL is nullptr
48547 </pre></blockquote>
48550 Possible resolutions:
48554 Forbid <tt>NULL</tt> from being <tt>nullptr</tt>
48557 Require <tt>NULL</tt> to be <tt>nullptr</tt>
48565 Making <tt>NULL</tt> <tt>nullptr</tt> would improve code correctness, and
48566 breaking backwards compatibility shouldn't be a huge concern as <tt>NULL</tt>
48567 shouldn't be used except as a null pointer constant anyways.
48571 2010-02-10 Chris provided wording.
48576 2010 Pittsburgh: Moved to NAD, rationale added below.
48582 <p><b>Rationale:</b></p>
48584 The LWG discussed the proposed resolution and several other options. There was
48585 no concensus to make this or any other changes.
48589 <p><b>Proposed resolution:</b></p>
48591 18.2 [support.types]
48596 3 The macro <tt>NULL</tt> <ins>is defined to be <tt>nullptr</tt>.</ins> <del>is
48597 an implementation-defined C++ null pointer constant in this International
48598 Standard (4.10).<sup>196</sup></del>
48602 196) Possible definitions include <tt>0</tt> and <tt>0L</tt>, but not
48612 7 The contents are the same as the Standard C library header
48613 <tt><string.h></tt>, with the change to <tt>memchr()</tt> specified in
48614 21.6 <ins>and the macro <tt>NULL</tt> defined to be <tt>nullptr</tt></ins>.
48623 2 The contents are the same as the Standard C library header
48624 <tt><time.h></tt><del>.</del><sup>232</sup> <ins>except the macro
48625 <tt>NULL</tt>, which is defined to be <tt>nullptr</tt>.</ins> The functions
48626 <tt>asctime</tt>, <tt>ctime</tt>, <tt>gmtime</tt>, and <tt>localtime</tt> are
48627 not required to avoid data races (17.6.4.8).
48636 2 The contents are the same as the Standard C library header
48637 <tt><locale.h></tt> <ins>except the macro <tt>NULL</tt>, which is defined
48638 to be <tt>nullptr</tt></ins>.
48642 C.2.2.4 [diff.null]
48646 1 The macro <tt>NULL</tt>, defined in any of <tt><clocale></tt>,
48647 <tt><cstddef></tt>, <tt><cstdio></tt>, <tt><cstdlib></tt>,
48648 <tt><cstring></tt>, <tt><ctime></tt>, or <tt><cwchar></tt>, is
48649 <ins>nullptr</ins> <del>an implementation-defined C++ null pointer constant in
48650 this International Standard (18.2).</del>
48659 <h3><a name="1315"></a>1315. return type of <tt>async</tt></h3>
48660 <p><b>Section:</b> 30.6.9 [futures.async] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
48661 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-02-09 <b>Last modified:</b> 2010-10-23</p>
48662 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.async">issues</a> in [futures.async].</p>
48663 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
48664 <p><b>Discussion:</b></p>
48666 Both overloads of <tt>async</tt> return <tt>future<typename
48667 F::result_type></tt> which requires that <tt>F</tt> has a nested type. This
48668 prevents <tt>async</tt> being used with function pointers and makes the example
48669 in 30.6.9 [futures.async] invalid. I believe this is unintentional.
48673 The proposed resolution also addresses editorial issues with the
48674 <tt>launch_policy</tt> function parameter.
48678 For the first overload it is not sufficient to return <tt>future<typename
48679 result_of<F(ArgTypes...)>::type></tt>. Calling <tt>async(launch::xxx,
48680 foo, bar)</tt> performs argument deduction on both <tt>async</tt> overloads,
48681 which for the first overload attempts to instantiate <tt>result_of<launch(F,
48682 ArgTypes...)></tt>, which is invalid. SFINAE must be used to prevent that.
48686 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
48691 2010-02-12 Daniel opens:
48697 [..] if <tt>decay<F>::type</tt> is of type <tt>std::launch</tt>.
48703 [..] if <tt>remove_cv<remove_reference<F>::type>::type</tt> is of
48704 type <tt>std::launch</tt>.
48708 The latter is the more specific form, but the former is equivalent to
48709 the latter for all cases that can occur here. I suggest to use the
48710 former for simplicity, but expect that implementations can effectively
48717 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
48727 Moved to NAD Editorial. Rationale added below.
48732 <p><b>Rationale:</b></p>
48738 <p><b>Proposed resolution:</b></p>
48740 In 30.6.1 [futures.overview] paragraph 1:
48743 <blockquote><pre>template <class F, class... Args>
48744 <del>future<typename F::result_type></del>
48745 <ins>future<typename result_of<F(Args...)>::type></ins>
48746 async(F&& f, Args&&... args);
48747 template <class F, class... Args>
48748 <del>future<typename F::result_type></del>
48749 <ins>future<typename result_of<F(Args...)>::type></ins>
48750 async(launch policy, F&& f, Args&&... args);
48751 </pre></blockquote>
48754 In 30.6.9 [futures.async] before paragraph 1
48757 <blockquote><pre>template <class F, class... Args>
48758 <del>future<typename F::result_type></del>
48759 <ins>future<typename result_of<F(Args...)>::type></ins>
48760 async(F&& f, Args&&... args);
48761 template <class F, class... Args>
48762 <del>future<typename F::result_type></del>
48763 <ins>future<typename result_of<F(Args...)>::type></ins>
48764 async(launch policy, F&& f, Args&&... args);
48769 <i>Remarks:</i> The first signature shall not participate in overload resolution
48770 if <tt>decay<F>::type</tt> is <tt>std::launch</tt>.
48781 <h3><a name="1317"></a>1317. make_hash</h3>
48782 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
48783 <b>Submitter:</b> Nicolai M. Josuttis <b>Opened:</b> 2010-02-10 <b>Last modified:</b> 2010-10-23</p>
48784 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
48785 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
48786 <p><b>Discussion:</b></p>
48788 Currently, the library lacks a convenient way to provide a hash function that
48789 can be used with the provided unordered containers to allow the usage of non
48790 trivial element types.
48794 While we can easily declare an
48797 <blockquote><pre>std::unordered_set<int>
48798 </pre></blockquote>
48804 <blockquote><pre>std::unordered_set<std::string>
48805 </pre></blockquote>
48808 we have no easy way to declare an <tt>unordered_set</tt> for a user defined
48809 type. IMO, this is a big obstacle to use unordered containers in practice. Note
48810 that in Java, the wide usage of <tt>HashMap</tt> is based on the fact that there
48811 is always a default hash function provided.
48815 Of course, a default hash function implies the risk to provide poor hash
48816 functions. But often even poor hash functions are good enough.
48820 While I really would like to see a default hash function, I don't propose it
48821 here because this would probably introduce a discussion that's too big for this
48826 However, I strongly suggest at least to provide a convenience variadic template
48827 function <tt>make_hash<>()</tt> to allow an easy definition of a (possibly
48828 poor) hash function.
48832 As a consequence for a user-defined type such as
48835 <blockquote><pre>class Customer {
48836 friend class CustomerHash;
48843 </pre></blockquote>
48846 would allow to specify:
48849 <blockquote><pre>class CustomerHash : public std::unary_function<Customer, std::size_t>
48852 std::size_t operator() (const Customer& c) const {
48853 return make_hash(c.firstname,c.lastname,c.no);
48856 </pre></blockquote>
48862 <blockquote><pre>class CustomerHash : public std::unary_function<Customer, std::size_t>
48865 std::size_t operator() (const Customer& c) const {
48866 return std::hash<std::string>()(c.firstname) +
48867 std::hash<std::string>()(c.lastname) +
48868 std::hash<long>()(c.no);
48871 </pre></blockquote>
48874 Note that, in principle, we can either specify that
48878 <tt>make_hash</tt> returns the sum of a call of
48879 <tt>std::hash<T>()(x)</tt> for each argument <tt>x</tt> of type
48884 or we can specify that
48888 <tt>make_hash</tt> provides a hash value for each argument, for which a
48889 <tt>std::hash()</tt> function is provided
48893 with the possible note that the hash value may be poor or only a good hash value
48894 if the ranges of all passed arguments is equally distributed.
48898 For my convenience, I propose wording that describes
48899 the concrete implementation.
48903 2010 Pittsburgh: Moved to NAD Editorial, rationale added below.
48909 <p><b>Rationale:</b></p>
48911 There is no consensus to make this change at this time.
48915 <p><b>Proposed resolution:</b></p>
48917 In Function objects 20.8 [function.objects]
48918 in paragraph 2 at the end of the Header <tt><functional></tt> synopsis
48922 <blockquote><pre>// convenience functions
48923 template <class T>
48924 size_t make_hash (const T&);
48925 template <class T, class... Types>
48926 size_t make_hash (const T&, const Types&...);
48927 </pre></blockquote>
48930 In Class template hash 20.8.15 [unord.hash]
48936 <b>20.7.16.1 Hash creation functions [hash.creation]</b>
48939 <pre>template <class T>
48940 size_t make_hash (const T& val);
48944 <i>Returns:</i> <tt>hash<T>()(val);</tt>
48947 <pre>template <class T, class... Types>
48948 size_t make_hash (const T& val, const Types&... args);
48952 <i>Returns:</i> <tt>hash<T>()(val) + std::make_hash(args...)</tt>
48963 <h3><a name="1329"></a>1329. Data races on <code>vector<bool></code></h3>
48964 <p><b>Section:</b> 23.2.2 [container.requirements.dataraces] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
48965 <b>Submitter:</b> Jeffrey Yaskin <b>Opened:</b> 2010-03-09 <b>Last modified:</b> 2010-10-23</p>
48966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
48967 <p><b>Discussion:</b></p>
48969 The common implementation of <tt>vector<bool></tt> is as an
48970 unsynchronized bitfield. The addition of 23.2.2 [container.requirements.dataraces]/2 would require either a
48971 change in representation or a change in access synchronization, both of
48972 which are undesireable with respect to compatibility and performance.
48976 2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.
48982 <p><b>Rationale:</b></p>
48985 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3069.html">N3069</a>.
48989 <p><b>Proposed resolution:</b></p>
48991 Container data races 23.2.2 [container.requirements.dataraces]
48995 Paragraph 1 is unchanged as follows:
48999 1 For purposes of avoiding data races (17.6.4.8), implementations shall
49000 consider the following functions to be <code>const</code>:
49001 <code>begin</code>, <code>end</code>, <code>rbegin</code>,
49002 <code>rend</code>, <code>front</code>, <code>back</code>,
49003 <code>data</code>, <code>find</code>, <code>lower_bound</code>,
49004 <code>upper_bound</code>, <code>equal_range</code>, and, except in
49005 associative containers, <code>operator[]</code>.
49009 Edit paragraph 2 as follows:
49013 2 Notwithstanding (17.6.4.8), implementations are required to avoid data
49014 races when the contents of the contained object in different elements in
49015 the same sequence<ins>, excepting <code>vector<bool></code>,</ins>
49016 are modified concurrently.
49020 Edit paragraph 3 as follows:
49025 For a <code>vector<int> x</code> with a size greater than one,
49026 <code>x[1] = 5</code> and <code>*x.begin() = 10</code>
49027 can be executed concurrently without a data race,
49028 but <code>x[0] = 5</code> and <code>*x.begin() = 10</code>
49029 executed concurrently may result in a data race.
49030 <ins>As an exception to the general rule,
49031 for a <code>vector<bool> y</code>,
49032 <code>y[i] = true</code> may race with <code>y[j] = true</code>.</ins>
49033 \97<i>end note</i>]
49042 <h3><a name="1331"></a>1331. incorporate move special member functions into library</h3>
49043 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49044 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2010-03-10 <b>Last modified:</b> 2010-11-29</p>
49045 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
49046 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
49047 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49048 <p><b>Discussion:</b></p>
49050 Review the library portion of the spec and incorporate the newly added
49051 core feature Move Special Member Functions (N3044).
49054 <p><b>Rationale:</b></p>
49055 2010 Batavia: This has now been done to a large extent.
49060 <p><b>Proposed resolution:</b></p>
49067 <h3><a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
49068 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49069 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-25</p>
49070 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
49071 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
49072 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49073 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1421">1421</a></p>
49074 <p><b>Discussion:</b></p>
49075 <p><b>Addresses CH-15</b></p>
49077 Due to the new rules about implicit copy and move
49078 constructors some library facilities are now move-only.
49082 Resolution proposed by ballot comment
49086 Make them copyable again.
49090 <p><b>Proposed resolution:</b></p>
49097 <h3><a name="1351"></a>1351. [FCD] Replace dynamic exception specifications with <tt>noexcept</tt></h3>
49098 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49099 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-25</p>
49100 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
49101 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
49102 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49103 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1344">1344</a></p>
49104 <p><b>Discussion:</b></p>
49106 <p><b>Addresses CH-16</b></p>
49108 Dynamic exception specifications are deprecated.
49109 Deprecated features shouldn't be used in the Standard.
49113 Resolution proposed by ballot comment
49117 Replace dynamic exception specifications with <tt>noexcept</tt>.
49121 <p><b>Proposed resolution:</b></p>
49128 <h3><a name="1352"></a>1352. [FCD] Apply <tt>noexcept</tt> where library specification says "Throws: Nothing"</h3>
49129 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49130 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-25</p>
49131 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
49132 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
49133 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49134 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1346">1346</a></p>
49135 <p><b>Discussion:</b></p>
49137 <p><b>Addresses CH-17</b></p>
49139 The introduction of <tt>noexcept</tt> makes "Throws: Nothing" clauses looking strange.
49143 Resolution proposed by ballot comment
49147 Consider replacing "Throws: Nothing." clause by
49148 the respective noexcept specification.
49153 <p><b>Proposed resolution:</b></p>
49160 <h3><a name="1359"></a>1359. [FCD] Add <tt><tuple></tt> and <tt><utility></tt> to freestanding implementations</h3>
49161 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49162 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49163 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
49164 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49165 <p><b>Discussion:</b></p>
49166 <p><b>Addresses GB-56</b></p>
49168 The <tt><utility></tt> header provides support for several
49169 important C++ idioms with <tt>move</tt>, <tt>forward</tt> and <tt>swap</tt>.
49170 Likewise, <tt>declval</tt> will be frequently used like a type trait.
49171 In order to complete cycles introduced by <tt>std::pair</tt>, the
49172 <tt><tuple></tt> header should also be made available. This is a
49173 similarly primitive set of functionality, with no dependency
49174 of a hosted environment, but does go beyond the minimal
49175 set of functionality otherwise suggested by the
49176 freestanding libraries.
49179 Alternatively, split the <tt>move</tt>/<tt>forward</tt>/<tt>swap</tt>/<tt>declval</tt>
49180 functions out of <tt><utility></tt> and into a new primitive header,
49181 requiring only that of freestanding implementation.
49185 Summary of Rapperswil discusions
49189 The preference of the meeting was to extract the rvalue-reference related utilities and swap into a freestanding header, but there was no clear preference for a name. Howard suggested simply dropping them into <tt><type_traits></tt> as both these utilities and type traits are used pretty much everywhere in the library implementation, it is the most convenient place to keep them (from an implementer's perspective).
49193 Poll: Two-way: New header for forward, move, swap, move_with_noexcept and declval vs. calling out forward, move, swap, move_with_noexcept and declval as freestanding explicitly?
49195 SF new header: 4 WF new header: 3 WF call out as freestanding: 1 SF call out as freestanding: 2
49197 Alisdair: Willing to write up both solutions, give us some time to think on it.
49199 Action: Need an issue and proposed wording for GB 56 - Alisdair to draft both options as in the last poll.
49203 Resolution proposed by ballot comment
49208 Add <tt><utility></tt> and <tt><tuple></tt> to table 15, headers
49209 required for a free-standing implementation.
49218 Closed as NAD, reversing the decision at Rapperswil.
49221 The consensus was that
49222 any freestanding implementation is going to feel compelled to offer the important
49223 features of <tt><utility></tt> even if we do not make them a freestanding
49224 requirement; breaking out additional small headers may have additional costs at
49225 compile time, and while the critical <tt>move</tt>-related functions could migrate
49226 to <tt><type_traits></tt>, the header name is far from appealing; adding the
49227 whole of <tt><utility></tt> starts to drag in dependencies on <tt><tuple></tt>
49228 and <tt><memory></tt>, so we prefer to place the burden of slicing or supporting
49229 this whole header on free-standing vendors.
49234 <p><b>Proposed resolution:</b></p>
49237 <p><b>Rationale:</b></p>No consensus for a change at this time.
49244 <h3><a name="1361"></a>1361. [FCD] Does use of <tt>std::size_t</tt> in a header imply that typedef name is available to users?</h3>
49245 <p><b>Section:</b> 17.6.2 [using] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49246 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49247 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49248 <p><b>Discussion:</b></p>
49249 <p><b>Addresses GB-58</b></p>
49251 It is not clear whether a library header specified in terms
49252 of a typedef name makes that same typedef name
49253 available for use, or if it simply requires that the specified
49254 type is an alias of the same type, and so the typedef name
49255 cannot be used without including the specific header that
49256 defines it. For example, is the following code required to
49259 <blockquote><pre>#include <vector>
49261 </pre></blockquote>
49263 Most often, this question concerns the typedefs defined in
49264 header <tt><cstddef></tt>
49268 Resolution proposed by ballot comment:
49272 Add a paragraph under 17.6.2 [using] clarifying whether
49273 or not headers specified in terms of <tt>std::size_t</tt> can
49274 be used to access the typedef <tt>size_t</tt>, or whether
49275 the header <tt><cstddef></tt> must be included to reliably
49278 <p><i>[Batavia: NAD - see rationale below]</i></p>
49283 <p><b>Proposed resolution:</b></p>
49285 <p><b>Rationale:</b></p>The standard is correct as written.
49291 <h3><a name="1373"></a>1373. [FCD] Customizable traits should have their own headers</h3>
49292 <p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49293 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49294 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility">issues</a> in [utility].</p>
49295 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49296 <p><b>Discussion:</b></p>
49297 <p><b>Addresses GB-79</b></p>
49299 The library provides several traits mechanisms intended a
49300 customization points for users. Typically, they are
49301 declared in headers that are growing quite large. This is
49302 not a problem for standard library vendors, who can
49303 manage their internal file structure to avoid large
49304 dependencies, but can be a problem for end users who
49305 have no option but to include these large headers.
49313 There was no enthusiasm for touching <tt>char_traits</tt> or <tt>regex_traits</tt>.
49314 Consensus to move <tt>iterator_traits</tt>, <tt>allocator_traits</tt>
49315 and <tt>pointer_traits</tt> to their own respective headers once wording supplied.
49323 After some discussion, consensus is that moving these features into separate
49324 headers does not buy much in practice, as the larger headers will inevitably
49325 be included anyway. Resolve as NAD.
49329 Resolution proposed in ballot comment
49333 Move the following traits classes into their own
49334 headers, and require the existing header to
49335 <tt>#include</tt> the traits header to support backwards
49338 <blockquote><pre>iterator_traits (plus the iterator tag-types)
49343 </pre></blockquote>
49350 Closed as NAD with the rationale below.
49355 <p><b>Rationale:</b></p>
49356 This suggest is not a defect, as the likely benefit is small, if any,
49357 compared to the cost of not just implementating the feature, but also
49358 explaining/teaching it.
49361 <p><b>Proposed resolution:</b></p>
49368 <h3><a name="1375"></a>1375. [FCD] <tt>reference_type</tt> should not have been removed from the
49369 allocator requirements</h3>
49370 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49371 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
49372 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
49373 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49374 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1318">1318</a></p>
49375 <p><b>Discussion:</b></p>
49377 <p><b>Addresses US-87</b></p>
49379 <tt>reference_type</tt> should not have been removed from the
49380 allocator requirements. Even if it is always the same as
49381 <tt>value_type&</tt>, it is an important customization point for
49382 extensions and future features.
49386 <p><b>Proposed resolution:</b></p>
49388 In [allocator.requirements] Table 42 - Allocotor Requirements,
49389 Add a row (after <tt>value_type</tt>) with columns:
49392 Expression: <ins><tt>X::reference_type</tt></ins><br>
49393 Return type: <ins><tt>T&</tt></ins><br>
49394 Assertion/note...: (empty)<br>
49395 Default: <ins><tt>T&</tt></ins><br>
49398 [allocator.traits]:
49400 <blockquote><pre>namespace std {
49401 template <class Alloc> struct allocator_traits {
49402 typedef Alloc allocator_type;
49404 typedef typename Alloc::value_type value_type;
49406 typedef <i>see below</i> pointer;
49407 typedef <i>see below</i> const_pointer;
49408 typedef <i>see below</i> void_pointer;
49409 typedef <i>see below</i> const_void_pointer;
49410 <ins>typedef value_type& reference_type;</ins>
49411 </pre></blockquote>
49413 Add <tt>reference_type</tt> to
49414 allocator_traits template, defaulted to
49422 <h3><a name="1376"></a>1376. [FCD] Allocator interface is not backward compatible</h3>
49423 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49424 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49425 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
49426 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49427 <p><b>Discussion:</b></p>
49428 <p><b>Addresses US-88</b></p>
49430 Allocator interface is not backward compatible.
49434 Resolution proposed by ballot comment
49438 See Appendix 1 - Additional Details
49442 2010-10-24 Daniel adds:
49447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3165.pdf">n3165</a> provides an alternative resolution.
49455 Closed as NAD - withdrawn by the submitter.
49459 <p><b>Proposed resolution:</b></p>
49460 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3165.pdf">n3165</a>
49463 <p><b>Rationale:</b></p>Withdrawn by the submitter.
49469 <h3><a name="1395"></a>1395. [FCD] Ballot Comment JP-32</h3>
49470 <p><b>Section:</b> 20.7.6 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
49471 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49472 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
49473 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
49474 <p><b>Discussion:</b></p>
49475 <p><b>Addresses JP-32</b></p>
49477 Representations of reference link are not unified.
49478 Most reference links to clause (table) number, say X, are
49479 in the form "Clause X" ("Table X") capitalized, and
49480 subsection Y.Y.Y is referenced with its number only in the
49481 form "Y.Y.Y". Whether they are parenthesized or not
49482 depends on the context.
49483 However there are some notations "(Z)" consisting of only
49484 a number Z in parentheses to confer Clause or Table
49489 <p><b>Proposed resolution:</b></p>
49490 Change "(10)" to "(Clause 10)".
49497 <h3><a name="1398"></a>1398. [FCD] Users should be able to specialize functors without depending on whole <tt><functional></tt> header</h3>
49498 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
49499 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49500 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
49501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
49502 <p><b>Discussion:</b></p>
49503 <p><b>Addresses GB-96</b></p>
49505 The function templates <tt>hash</tt>, <tt>less</tt> and <tt>equal_to</tt>
49506 are important customization points for user-defined types to
49507 be supported by several standard containers. These are
49508 accessed through the <tt><functional></tt> header which has
49509 grown significantly larger in C++0x, exposing many more
49510 facilities than a user is likely to need through there own
49511 header, simply to declare the necessary specialization.
49512 There should be a smaller header available for users to
49513 make the necessary customization.
49517 Resolution proposed by ballot comment
49521 Provide a tiny forwarding header for important
49522 functor types in the <tt><functional></tt> header that a
49523 user may want to specialize. This should contain
49524 the template declaration for <tt>equal_to</tt>, <tt>hash</tt> and
49529 Rapperswill summary
49532 <p>Alisdair: Would recommend NAD unless someone takes the issue. </p>
49534 <p>Daniel: Volunteers to write a paper for this. </p>
49537 2010-11-07 Daniel provides a paper available on the Batavia document list
49546 Closed as NAD - the consensus was that forwarding headers such as
49547 <tt><iosfwd></tt> do not bring the expected benefits, and are
49548 not widely used (to the surprise of some active users in the room!).
49549 Without real experience reporting a benefit, there is no further interest
49550 in pursuing this issue as an extension - hence NAD rather than NAD Future.
49555 <p><b>Rationale:</b></p>No consensus to make a change
49557 <p><b>Proposed resolution:</b></p>
49558 See paper "Forwarding <tt><functional></tt> functor templates"
49559 on the Batavia LWG document list
49566 <h3><a name="1406"></a>1406. [FCD] Support hashing smart-pointers based on <i>owner</i></h3>
49567 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
49568 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49569 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
49570 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
49571 <p><b>Discussion:</b></p>
49572 <p><b>Addresses JP-5</b></p>
49574 Hash support based on ownership sharing should be
49575 supplied for <tt>shared_ptr</tt> and <tt>weak_ptr</tt>.
49576 For two <tt>shared_ptr</tt> objects <tt>p</tt> and <tt>q</tt>, two distinct
49577 equivalence relations can be defined. One is based on
49578 equivalence of pointer values, which is derived from the
49579 expression <tt>p.get() == q.get()</tt> (hereafter called <i>address based
49580 equivalence relation</i>), the other is based on
49581 equivalence of ownership sharing, which is derived from
49582 the expression <tt>!p.owner_before(q) && !q.owner_before(p)</tt>
49583 (hereafter called <i>ownership-based equivalence relation</i>).
49584 These two equivalence relations are independent in
49585 general. For example, a <tt>shared_ptr</tt> object created by the
49586 constructor of the signature <tt>shared_ptr(shared_ptr<U>
49587 const &, T *)</tt> could reveal a difference between these two
49588 relations. Therefore, hash support based on each
49589 equivalence relation should be supplied for <tt>shared_ptr</tt>.
49590 However, while the standard library provides the hash
49591 support for address-based one (20.9.11.6 paragraph 2), it
49592 lacks the hash support for ownership-based one. In
49593 addition, associative containers work well in combination
49594 with the <tt>shared_ptr</tt>'s ownership-based comparison but
49595 unordered associative containers don't. This is
49599 For the case of <tt>weak_ptr</tt>, hash support for the ownership based
49600 equivalence relation can be safely defined on
49601 <tt>weak_ptr</tt>s, and even on expired ones. The absence of
49602 hash support for the ownership-based equivalence
49603 relation is fatal, especially for expired <tt>weak_ptr</tt>s. And the
49604 absence of such hash support precludes some quite
49605 effective use-cases, e.g. erasing the <tt>unordered_map</tt> entry
49606 of an expired <tt>weak_ptr</tt> key from a customized deleter
49607 supplied to <tt>shared_ptr</tt>s.
49610 Hash support for the ownership-based equivalence
49611 relation cannot be provided by any user-defined manner
49612 because information about ownership sharing is not
49613 available to users at all. Therefore, the only way to provide
49614 ownership-based hash support is to offer it intrusively by
49615 the standard library.
49618 As far as we know, such hash support is implementable.
49619 Typical implementation of such hash function could return
49620 the hash value of the pointer of the counter object that is
49621 internally managed by <tt>shared_ptr</tt> and <tt>weak_ptr</tt>.
49624 <p><i>[2010 Rapperswil:]</i></p>
49627 <p>No consensus to make this change at this time.</p>
49631 <p><b>Proposed resolution:</b></p>
49633 Add the following non-static member functions to
49634 <tt>shared_ptr</tt> and <tt>weak_ptr</tt> class template;
49637 Update [util.smartptr.shared], 20.9.11.2 paragraph 1
49639 <pre>namespace std{
49640 template<class T> class shared_ptr {
49643 <ins>size_t owner_hash() const;</ins>
49649 Update [util.smartptr.weak], 20.9.11.3 paragraph 1
49651 <pre>namespace std{
49652 template<class T> class weak_ptr {
49655 <ins>size_t owner_hash() const;</ins>
49661 These functions satisfy the following
49662 requirements. Let <tt>p</tt> and <tt>q</tt> be objects of either
49663 <tt>shared_ptr</tt> or <tt>weak_ptr</tt>, <tt>H</tt> be a hypothetical
49664 function object type that satisfies the hash
49665 requirements ([hash.requirements], 20.2.4) and <tt>h</tt> be an object of the
49666 type <tt>H</tt>. The expression <tt>p.owner_hash()</tt> behaves
49667 as if it were equivalent to the expression <tt>h(p)</tt>. In
49668 addition, <tt>h(p) == h(q)</tt> must become <tt>true</tt> if <tt>p</tt> and
49669 <tt>q</tt> share ownership.
49677 <h3><a name="1411"></a>1411. [FCD] Add a compile-time flag to detect <tt>monotonic_clock</tt></h3>
49678 <p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49679 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-26</p>
49680 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.monotonic">issues</a> in [time.clock.monotonic].</p>
49681 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49682 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1410">1410</a></p>
49683 <p><b>Discussion:</b></p>
49685 <p><b>Addresses DE-20</b></p>
49687 The library component <tt>monotonic_clock</tt> is conditionally
49688 supported, but no compile-time flag exists that allows
49689 user-code to query its existence. Further-on there exist no
49690 portable means to simulate such a query. (To do so, user
49691 code would be required to add types to namespace
49692 <tt>std::chrono</tt>.)
49695 <p><b>Proposed resolution:</b></p>
49696 Provide a compile-time flag (preferably a macro)
49697 that can be used to query the existence of
49698 <tt>monotonic_clock</tt>.
49705 <h3><a name="1415"></a>1415. [FCD] iterator stability bans the short-string optimization</h3>
49706 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
49707 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
49708 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
49709 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
49710 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
49711 <p><b>Discussion:</b></p>
49712 Requirements on iterators swapping allegiance would
49713 disallow the small-string optimization.
49716 Resolved in Rapperswil by paper N3108.
49722 <p><b>Proposed resolution:</b></p>
49723 Add an exclusion for <tt>basic_string</tt> to the sentence
49724 beginning
\93Every iterator referring to an
49725 element...
\94. Add a sentence to 21.4.6.8/2 saying
49726 that iterators and references to string elements
49727 remain valid, but it is not specified whether they
49728 refer to the same string or the other string.
49735 <h3><a name="1419"></a>1419. [FCD] Ballot Comment US-117</h3>
49736 <p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
49737 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
49738 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist">issues</a> in [forwardlist].</p>
49739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
49740 <p><b>Discussion:</b></p>
49741 <p><b>Addresses US-117</b></p>
49743 forward_list::erase_after should return an iterator.
49746 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
49752 <p><b>Proposed resolution:</b></p>
49753 See Appendix 1 - Additional Details
49760 <h3><a name="1422"></a>1422. [FCD] vector<bool> iterators are not random access</h3>
49761 <p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
49762 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
49763 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
49764 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
49765 <p><b>Discussion:</b></p>
49766 <p><b>Addresses GB-118</b></p>
49768 <tt>vector<bool></tt> iterators are not random access iterators
49769 because their reference type is a special class, and not
49770 <tt>bool &</tt>. All standard libary operations taking iterators
49771 should treat this iterator as if it was a random access iterator, rather
49772 than a simple input iterator.
49776 Resolution proposed in ballot comment
49780 Either revise the iterator requirements to support proxy iterators
49781 (restoring functionality that was lost when the Concept facility was
49782 removed) or add an extra paragraph to the <tt>vector<bool></tt>
49783 specification requiring the library to treat <tt>vector<bool></tt>
49784 iterators as-if they were random access iterators, despite having the wrong
49793 The consensus at Rapperswil is that it is too late for full support for
49794 proxy iterators, but requiring the library to respect <tt>vector&;t;bool></tt>
49795 iterators as-if they were random access would be preferable to flagging
49796 this container as deliberately incompatible with standard library algorithms.
49799 Alisdair to write the note, which may become normative <i>Remark</i> depending
49800 on the preferences of the project editor.
49804 Post-Rapperswil Alisdair provides wording
49808 Initial wording is supplied, deliberately using <i>Note</i> in preference to
49809 <i>Remark</i> although the author notes his preference for <i>Remark</i>. The
49810 issue of whether <tt>iterator_traits<vector<bool>>::iterator_category</tt>
49811 is permitted to report <tt>random_access_iterator_tag</tt> or must report
49812 <tt>input_iterator_tag</tt> is not addressed.
49816 Old Proposed Resolution:
49821 Insert a new paragraph into 23.4.2 [vector.bool] between p4 and p5:
49824 [<i>Note</i> All functions in the library that take a pair of iterators to
49825 denote a range shall treat <tt>vector<bool></tt> iterators as-if they were
49826 random access iterators, even though the <tt>reference</tt> type is not a
49827 true reference.<i>-- end note</i>]
49836 Closed as NAD Future, because the current iterator categories cannot correctly describe
49837 <tt>vector<bool>::iterator</tt>. But saying that they are Random Access Iterators
49838 is also incorrect, because it is not too hard to create a corresponding test that fails.
49839 We should deal with the more general proxy iterator problem in the future, and see no
49840 benefit to take a partial workaround specific to <tt>vector<bool></tt> now.
49845 <p><b>Proposed resolution:</b></p>
49848 <p><b>Rationale:</b></p>
49849 No consensus to make this change at this time.
49856 <h3><a name="1433"></a>1433. [FCD] Ballot Comment GB-119</h3>
49857 <p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
49858 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
49859 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
49860 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
49861 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1432">1432</a></p>
49862 <p><b>Discussion:</b></p>
49863 <p><b>Addresses GB-119</b></p>
49865 The functions random_shuffle and shuffle both take
49866 arguments providing a source of randomness, but one
49867 take its argument by rvalue reference, and the other
49868 requires an lvalue reference. The technical merits of which
49869 form of argument passing should be settled for this
49870 specific case, and a single preferred form used
49874 <p><b>Proposed resolution:</b></p>
49875 [DEPENDS ON WHETHER RVALUE OR
49876 LVALUE REFERENCE IS THE PREFERRED
49884 <h3><a name="1434"></a>1434. [FCD] Ballot Comment US-122</h3>
49885 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
49886 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
49887 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
49888 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
49889 <p><b>Discussion:</b></p>
49890 <p><b>Addresses US-122</b></p>
49892 It was the LWG's intent in Pittsburgh that N2772 be
49896 Resolved in Rapperswil by paper N3106.
49902 <p><b>Proposed resolution:</b></p>
49903 Apply N2772 to the WP.
49910 <h3><a name="1442"></a>1442. [FCD] "happens-before" should be "synchronizes-with"</h3>
49911 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
49912 <b>Submitter:</b> Canada <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-18</p>
49913 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
49914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
49915 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1443">1443</a></p>
49916 <p><b>Discussion:</b></p>
49917 <p><b>Addresses CA-9, GB-122</b></p>
49919 <p><i>[CA-9:]</i></p>
49922 Imposed happens-before edges should be in
49923 synchronizes-with<br>
49924 Each use of the words "happens-before" should be
49925 replaced with the words "synchronizes-with" in the
49926 following sentences:<br>
49933 Rationale: Happens-before is defined in 1.10p11 in a way
49934 that (deliberately) does not make it explicitly transitively
49935 closed. Adding edges to happens-before directly, as in
49936 27.2.3p2 etc., does not provide transitivity with
49937 sequenced-before or any other existing happens-before
49938 edge. This lack of transitivity seems to be unintentional.
49940 <p><i>[GB-122]</i></p>
49943 <p>At various points in the standard new edges are added to
49944 happens-before, for example 27.2.3:2 adds happens-before edges between
49945 writes and reads from a stream:</p>
49947 <p>If one thread makes a library call a that writes a value to a
49948 stream and, as a result, another thread reads this value from the
49949 stream through a library call b such that this does not result in a
49950 data race, then a happens before b.</p>
49952 <p>Happens-before is defined in 1.10:11 in a deliberate way that makes it
49953 not explicitly transitively closed. Adding edges to happens-before
49954 directly, as in 27.2.3:2, does not provide transitivity with
49955 sequenced-before or any other existing happens-before edge. This lack
49956 of transitivity seems to be unintentional. In order to achieve
49957 transitivity we suggest each edge be added to
49958 inter-thread-happens-before as a synchronises-with edge (as per
49959 conversation with Hans Boehm). In the standard, each use of the words
49960 "happens-before" should be replaced with the words "synchronizes-with"
49961 in the following sentences:</p>
49970 <p><b>Proposed resolution:</b></p>
49972 <p><i>[Beman provided specific wording for the proposed resolution.]</i></p>
49975 <p>Change 27.2.3 Thread Safety [iostreams.threadsafety] paragraph 2:</p>
49977 <p>If one thread makes a library call <tt>a</tt> that writes a value to a stream and, as a result, another thread reads this value from the stream through a library call <tt>b</tt> such that this does not result in a data race, then <tt>a</tt> <del>happens before</del> <ins>synchronizes with</ins> <tt>b</tt>.</p>
49979 <p>Change 30.3.1.2 thread constructors [thread.thread.constr] paragraph 6:</p>
49981 <p><i>Synchronization:</i> The invocation of the constructor <del>happens before</del> <ins>synchronizes with</ins> the invocation of the copy of <tt>f</tt>.</p>
49983 <p>Change 30.3.1.5 thread members [thread.thread.member] paragraph 7:</p>
49985 <p><i>Synchronization:</i> The completion of the thread represented by <tt>*this</tt> <del>happens before</del> <ins>synchronizes with</ins> (1.10) <tt>join()</tt> <del>returns</del> <ins>returning</ins>. [ Note: Operations on <tt>*this</tt> are not synchronized. --end note ]</p>
49987 <p>Change 30.6.4 Associated asynchronous state [futures.state] paragraph 7:</p>
49989 <p>Calls to functions that successfully set the stored result of an associated asynchronous state synchronize
49990 with (1.10) calls to functions successfully detecting the ready state resulting from that setting. The storage of the result (whether normal or exceptional) into the associated asynchronous state <del>happens before</del> <ins>synchronizes with</ins> (1.10) that state <del>is</del> <ins>being</ins> set to ready.</p>
49992 <p>Change 30.6.9 Function template async [futures.async] paragraph 5:</p>
49994 <p><i>Synchronization:</i> the invocation of <tt>async</tt> <del>happens before</del> <ins>synchronizes with</ins> (1.10) the invocation of <tt>f</tt>. [ Note: this
49995 statement applies even when the corresponding future object is moved to another thread. --end
49996 note ] If the invocation is not deferred, a call to a waiting function on an asynchronous return object
49997 that shares the associated asynchronous state created by this async call shall block until the associated
49998 thread has completed. If the invocation is not deferred, the <tt>join()</tt> on the created thread <del>happens before</del> <ins>synchronizes with</ins>
49999 (1.10) the first function that successfully detects the ready status of the associated asynchronous
50000 state returns or before the function that gives up the last reference to the associated asynchronous
50001 state returns, whichever happens first. If the invocation is deferred, the completion of the invocation
50002 of the deferred function <del>happens before</del> <ins>synchronizes with</ins> the calls to the waiting functions return.</p>
50004 <p>Change 30.6.10.1 packaged_task member functions [futures.task.members] paragraph 23:</p>
50006 <p><i>Synchronization:</i> a successful call to <tt>operator()</tt> synchronizes with (1.10) a call to any member function of a <tt>future</tt>, <tt>shared_future</tt>, or <tt>atomic_future</tt> object that shares the associated asynchronous
50007 state of <tt>*this</tt>. The completion of the invocation of the stored task and the storage of the result
50008 (whether normal or exceptional) into the associated asynchronous state <del>happens before</del> <ins>synchronizes with</ins> (1.10) the
50009 state <del>is</del> <ins>being</ins> set to ready. [ Note: <tt>operator()</tt> synchronizes and serializes with other functions through the
50010 associated asynchronous state.
\97end note ]</p>
50018 <h3><a name="1443"></a>1443. [FCD] Imposed happens-before edges are not made transitive</h3>
50019 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50020 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-27</p>
50021 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
50022 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50023 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1442">1442</a></p>
50024 <p><b>Discussion:</b></p>
50027 <p><b>Addresses GB-122</b></p>
50029 <p>At various points in the standard new edges are added to
50030 happens-before, for example 27.2.3:2 adds happens-before edges between
50031 writes and reads from a stream:</p>
50033 <p>If one thread makes a library call a that writes a value to a
50034 stream and, as a result, another thread reads this value from the
50035 stream through a library call b such that this does not result in a
50036 data race, then a happens before b.</p>
50038 <p>Happens-before is defined in 1.10:11 in a deliberate way that makes it
50039 not explicitly transitively closed. Adding edges to happens-before
50040 directly, as in 27.2.3:2, does not provide transitivity with
50041 sequenced-before or any other existing happens-before edge. This lack
50042 of transitivity seems to be unintentional. In order to achieve
50043 transitivity we suggest each edge be added to
50044 inter-thread-happens-before as a synchronises-with edge (as per
50045 conversation with Hans Boehm). In the standard, each use of the words
50046 "happens-before" should be replaced with the words "synchronizes-with"
50047 in the following sentences:</p>
50057 <p><b>Proposed resolution:</b></p>
50058 Request the concurrency working group to
50059 determine if changes are needed
50066 <h3><a name="1444"></a>1444. [FCD] <tt>OFF_T</tt> is not defined</h3>
50067 <p><b>Section:</b> 27.5.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50068 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-28</p>
50069 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos.operations">issues</a> in [fpos.operations].</p>
50070 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50071 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1414">1414</a></p>
50072 <p><b>Discussion:</b></p>
50074 <p><b>Addresses GB-123</b></p>
50076 Several rows in table 124 specify a Return type of
50077 'OFF_T', which does not appear to be a type defined in
50081 <p><b>Proposed resolution:</b></p>
50082 Resolve outstanding references to the removed
50090 <h3><a name="1446"></a>1446. [FCD] Move and swap for I/O streams</h3>
50091 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
50092 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50093 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
50094 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
50095 <p><b>Discussion:</b></p>
50096 <p><b>Addresses US-138</b></p>
50098 For istreams and ostreams, the move-constructor does
50099 not move-construct, the move-assignment operator does
50100 not move-assign, and the swap function does not swap
50101 because these operations do not manage the <tt>rdbuf()</tt>
50102 pointer. Useful applications of these operations are
50103 prevented both by their incorrect semantics and because
50104 they are protected.
50107 Resolution proposed by ballot comment:
50111 In short: reverse the resolution of issue 900, then
50112 change the semantics to move and swap the
50113 <tt>rdbuf()</tt> pointer. Add a new protected constructor
50114 that takes an rvalue reference to a stream and a
50115 pointer to a streambuf, a new protected <tt>assign()</tt>
50116 operator that takes the same arguments, and a
50117 new protected <tt>partial_swap()</tt> function that doesn't
50118 swap <tt>rdbuf()</tt>.
50119 See Appendix 1 - Additional Details
50123 2010-10-24 Daniel adds:
50128 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3179.pdf">n3179</a> would solve this issue.
50139 The Library Working Group reviewed <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3179.pdf">n3179</a> and
50140 concluded that this change alone was not sufficient, as it would require changes to some of the derived stream types in the library.
50141 The preference is to not make such a broad fix, and retain the current semantics. This is closed as NAD rather than NAD future as it
50142 will be difficult to rename the new functions introduced in the C++0x revision of the standard at a later date.
50147 <p><b>Proposed resolution:</b></p>
50154 <h3><a name="1451"></a>1451. [FCD] <tt>regex</tt> should support allocators</h3>
50155 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50156 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
50157 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
50158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50159 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1396">1396</a></p>
50160 <p><b>Discussion:</b></p>
50162 <p><b>Addresses US-141</b></p>
50164 std::basic_regex should have an allocator for all the
50165 reasons that a std::string does. For example, I can use
50166 boost::interprocess to put a string or vector in shared
50167 memory, but not a regex.
50170 <p><b>Proposed resolution:</b></p>
50171 Add allocators to regexes; see paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3171.pdf">N3171</a>
50172 in the pre-Batavia mailing.
50179 <h3><a name="1454"></a>1454. [FCD] Ensure C compatibility for atomics</h3>
50180 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50181 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-29</p>
50182 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
50183 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
50184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50185 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1455">1455</a></p>
50186 <p><b>Discussion:</b></p>
50188 <p><b>Addresses GB-128</b></p>
50190 WG14 has made some late changes to their specification
50191 of atomics, and care should be taken to ensure that we
50192 retain a common subset of language/library syntax to
50193 declare headers that are portable to both languages.
50194 Ideally, such headers would not require users to define
50195 their own macros, especially not macros that map to
50196 keywords (which remains undefined behaviour)
50201 Resolution proposed by ballot comment
50205 Depends on result of the review of WG14 work,
50206 which is expected to be out to ballot during the
50207 time wg21 is resolving its own ballot comments.
50208 Liaison may also want to file comments in WG14
50209 to ensure compatibity from both sides.
50213 <p><b>Proposed resolution:</b></p>
50220 <h3><a name="1458"></a>1458. [FCD] Overlapping evaluations are allowed</h3>
50221 <p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50222 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-26</p>
50223 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
50224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50225 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1459">1459</a></p>
50226 <p><b>Discussion:</b></p>
50228 <p><b>Addresses GB-131</b></p>
50230 29.4 [atomics.lockfree] p.8 states:
50231 <p></p><blockquote>
50232 An atomic store shall only store a value that has been computed
50233 from constants and program input values by a finite sequence of
50234 program evaluations, such that each evaluation observes the values
50235 of variables as computed by the last prior assignment in the
50237 </blockquote><p></p>
50239 ... but 1.9 [intro.execution] p.13 states:
50241 <p></p><blockquote>
50242 If A is not sequenced before B and B is not sequenced before A,
50243 then A and B are unsequenced. [ <em>Note</em>: The execution of unsequenced
50244 evaluations can overlap.
\97 <em>end note</em> ]
50245 </blockquote><p></p>
50247 Overlapping executions can make it impossible to construct the sequence
50248 described in 29.4 [atomics.lockfree] p.8. We are not sure of the intention here and do not
50249 offer a suggestion for change, but note that 29.4 [atomics.lockfree] p.8 is the condition
50250 that prevents out-of-thin-air reads.
50254 <p><b>Proposed resolution:</b></p>
50255 Request the concurrency working group to
50256 determine if changes are needed. Consider
50257 changing the use of "sequence" in 29.4 [atomics.lockfree]
50264 <h3><a name="1463"></a>1463. [FCD] Inconsistent value assignment for <tt>atomic_bool</tt></h3>
50265 <p><b>Section:</b> 29.5.1 [atomics.types.integral] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50266 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
50267 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.integral">issues</a> in [atomics.types.integral].</p>
50268 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50269 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1462">1462</a></p>
50270 <p><b>Discussion:</b></p>
50272 <p><b>Addresses US-157</b></p>
50274 <tt>atomic_bool</tt> has a <tt>volatile</tt> assignment operator but not a
50275 non-<tt>volatile</tt> operator. The other integral types have both.
50278 <p><b>Proposed resolution:</b></p>
50279 Add a non-volatile assignment operator to <tt>atomic_bool</tt>.
50286 <h3><a name="1470"></a>1470. [FCD] "Same-ness" curiosities</h3>
50287 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50288 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
50289 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50290 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50291 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50292 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a></p>
50293 <p><b>Discussion:</b></p>
50294 <p><b>Addresses US-165</b></p>
50296 According to 29.6 [atomics.types.operations] p. 23:
50297 <p></p><blockquote>
50298 \93is the same that same as that of
\94 is not grammatical (and is not clear)
50299 </blockquote><p></p>
50303 <p><b>Proposed resolution:</b></p>
50310 <h3><a name="1471"></a>1471. [FCD] Default constructor of atomics needs specification</h3>
50311 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50312 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-18</p>
50313 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50314 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50316 <p><b>Discussion:</b></p>
50317 <p><b>Addresses US-168</b></p>
50319 29.6 [atomics.types.operations] around p. 4: The definition of the default constructor needs exposition.
50322 <p><b>Proposed resolution:</b></p>
50323 Insert a new general prototype description following the current 29.6 [atomics.types.operations] p. 3 as indicated:
50327 3 [<em>Note</em>: Many operations are volatile-qualified. The
\93volatile as device register
\94 semantics have not changed
50328 in the standard. This qualification means that volatility is preserved when applying these operations to
50329 volatile objects. It does not mean that operations on non-volatile objects become volatile. Thus, volatile
50330 qualified operations on non-volatile objects may be merged under some conditions. -- <em>end note</em>]
50332 <blockquote><pre><ins>A::A() = default;</ins>
50334 <ins>? <em>Effects</em>: Leaves the atomic object in an uninitialized state.
50335 [<em>Note</em>: These semantics ensure compatiblity with <tt>C</tt>. -- <em>end note</em>]</ins>
50336 </blockquote></blockquote>
50337 <blockquote><pre>constexpr A::A(C desired);
50339 </pre></blockquote>
50346 <h3><a name="1472"></a>1472. [FCD] Incorrect semantics of <tt>atomic_init</tt></h3>
50347 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50348 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
50349 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50350 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50351 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50352 <p><b>Discussion:</b></p>
50353 <p><b>Addresses US-171</b></p>
50355 As of 29.6 [atomics.types.operations] p. 7:
50357 The <tt>atomic_init</tt> definition "Non-atomically assigns the
50358 value" is not quite correct, as the <tt>atomic_init</tt> purpose is
50362 </p><p><b>Proposed resolution:</b></p>
50363 Change 29.6 [atomics.types.operations] p. 7 as indicated:
50364 <blockquote><pre>void atomic_init(volatile A *object, C desired);
50365 void atomic_init(A *object, C desired);
50367 7 <em>Effects</em>: <del>Non-atomically assigns the value desired to <tt>*object</tt></del><ins>Initializes <tt>*object</tt> with value
50368 <tt>desired</tt></ins>. Concurrent access from another thread, even via an atomic operation, constitutes a data race.
50369 <ins>[<em>Note</em>: This function should only be applied to objects that have been default constructed. These semantics ensure
50370 compatibility with <tt>C</tt>.
\97 <em>end note</em>]</ins>
50371 </blockquote></blockquote>
50378 <h3><a name="1473"></a>1473. [FCD] Incomplete memory order specifications</h3>
50379 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
50380 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50381 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50382 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50383 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
50384 <p><b>Discussion:</b></p>
50385 <p><b>Addresses US-172</b></p>
50387 As of 29.6 [atomics.types.operations] p. 9, 13, 17, 20:
50389 The order specifications are incomplete because the non-<tt>_explicit</tt>
50390 functions do not have such parameters.
50392 Add a new sentence: "If the program does not specify an order, it shall be
50393 <tt>memory_order_seq_cst</tt>." Or perhaps: "The non-_explicit
50394 non-member functions shall affect memory as though they were _explicit with
50395 <tt>memory_order_seq_cst</tt>."
50403 The Concurrency subgroup reviewed this, and deemed it NAD according to
50404 29.6 [atomics.types.operations] paragraph 2, bullet 4.
50407 <p><b>Rationale:</b></p>The working paper is correct as written.
50411 <p><b>Proposed resolution:</b></p>
50413 <li>Change 29.6 [atomics.types.operations] p. 9 as indicated:
50414 <blockquote><pre>void atomic_store(volatile A* object, C desired);
50415 void atomic_store(A* object, C desired);
50416 void atomic_store_explicit(volatile A *object, C desired, memory_order order);
50417 void atomic_store_explicit(A* object, C desired, memory_order order);
50418 void A::store(C desired, memory_order order = memory_order_seq_cst) volatile;
50419 void A::store(C desired, memory_order order = memory_order_seq_cst);
50421 8 <em>Requires</em>: The order argument shall not be <tt>memory_order_consume</tt>, <tt>memory_order_acquire</tt>, nor
50422 <tt>memory_order_acq_rel</tt>.
50424 9 <em>Effects</em>: Atomically replaces the value pointed to by <tt>object</tt> or by this with the value of <tt>desired</tt>.
50425 Memory is affected according to the value of <tt>order</tt>. <ins>If the program does not specify an order, it shall be
50426 <tt>memory_order_seq_cst</tt>.</ins>
50427 </p></blockquote></blockquote>
50429 <li>Change 29.6 [atomics.types.operations] p. 13 as indicated:
50430 <blockquote><pre>C atomic_load(const volatile A* object);
50431 C atomic_load(const A* object);
50432 C atomic_load_explicit(const volatile A* object, memory_order);
50433 C atomic_load_explicit(const A* object, memory_order);
50434 C A::load(memory_order order = memory_order_seq_cst) const volatile;
50435 C A::load(memory_order order = memory_order_seq_cst) const;
50437 12 <em>Requires</em>: The order argument shall not be <tt>memory_order_release</tt> nor <tt>memory_order_acq_rel</tt>.
50439 13 <em>Effects</em>: Memory is affected according to the value of <tt>order</tt>. <ins>If the program does not specify an order, it shall be
50440 <tt>memory_order_seq_cst</tt>.</ins>
50442 14 <em>Returns</em>: Atomically returns the value pointed to by <tt>object</tt> or by <tt>this</tt>.
50443 </p></blockquote></blockquote>
50445 <li>Change 29.6 [atomics.types.operations] p. 17 as indicated:
50446 <blockquote><pre>C atomic_exchange(volatile A* object, C desired);
50447 C atomic_exchange(A* object, C desired);
50448 C atomic_exchange_explicit(volatile A* object, C desired, memory_order);
50449 C atomic_exchange_explicit(A* object, C desired, memory_order);
50450 C A::exchange(C desired, memory_order order = memory_order_seq_cst) volatile;
50451 C A::exchange(C desired, memory_order order = memory_order_seq_cst);
50453 17 <em>Effects</em>: Atomically replaces the value pointed to by <tt>object</tt> or by <tt>this</tt> with <tt>desired</tt>. Memory
50454 is affected according to the value of <tt>order</tt>. These operations are atomic read-modify-write operations
50455 (1.10). <ins>If the program does not specify an order, it shall be <tt>memory_order_seq_cst</tt>.</ins>
50457 18 <em>Returns</em>: Atomically returns the value pointed to by <tt>object</tt> or by <tt>this</tt> immediately before the effects.
50458 </p></blockquote></blockquote>
50460 <li>Change 29.6 [atomics.types.operations] p. 20 as indicated:
50461 <blockquote><pre>bool atomic_compare_exchange_weak(volatile A* object, C * expected, C desired);
50462 bool atomic_compare_exchange_weak(A* object, C * expected, C desired);
50463 bool atomic_compare_exchange_strong(volatile A* object, C * expected, C desired);
50464 bool atomic_compare_exchange_strong(A* object, C * expected, C desired);
50465 bool atomic_compare_exchange_weak_explicit(volatile A* object, C * expected, C desired,
50466 memory_order success, memory_order failure);
50467 bool atomic_compare_exchange_weak_explicit(A* object, C * expected, C desired,
50468 memory_order success, memory_order failure);
50469 bool atomic_compare_exchange_strong_explicit(volatile A* object, C * expected, C desired,
50470 memory_order success, memory_order failure);
50471 bool atomic_compare_exchange_strong_explicit(A* object, C * expected, C desired,
50472 memory_order success, memory_order failure);
50473 bool A::compare_exchange_weak(C & expected, C desired,
50474 memory_order success, memory_order failure) volatile;
50475 bool A::compare_exchange_weak(C & expected, C desired,
50476 memory_order success, memory_order failure);
50477 bool A::compare_exchange_strong(C & expected, C desired,
50478 memory_order success, memory_order failure) volatile;
50479 bool A::compare_exchange_strong(C & expected, C desired,
50480 memory_order success, memory_order failure);
50481 bool A::compare_exchange_weak(C & expected, C desired,
50482 memory_order order = memory_order_seq_cst) volatile;
50483 bool A::compare_exchange_weak(C & expected, C desired,
50484 memory_order order = memory_order_seq_cst);
50485 bool A::compare_exchange_strong(C & expected, C desired,
50486 memory_order order = memory_order_seq_cst) volatile;
50487 bool A::compare_exchange_strong(C & expected, C desired,
50488 memory_order order = memory_order_seq_cst);
50490 19 <em>Requires</em>: The <tt>failure</tt> argument shall not be <tt>memory_order_release</tt> nor <tt>memory_order_acq_rel</tt>.
50491 The <tt>failure</tt> argument shall be no stronger than the success argument.
50493 20 <em>Effects</em>: Atomically, compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> for equality
50494 with that in <tt>expected</tt>, and if true, replaces the contents of the memory pointed to by <tt>object</tt> or by
50495 <tt>this</tt> with that in <tt>desired</tt>, and if false, updates the contents of the memory in expected with the
50496 contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true, memory
50497 is affected according to the value of <tt>success</tt>, and if the comparison is false, memory is affected
50498 according to the value of <tt>failure</tt>. When only one <tt>memory_order</tt> argument is supplied, the value of
50499 <tt>success</tt> is <tt>order</tt>, and the value of <tt>failure</tt> is <tt>order</tt> except that a value of
50500 <tt>memory_order_acq_rel</tt> shall be replaced by the value <tt>memory_order_acquire</tt> and a value of
50501 <tt>memory_order_release</tt> shall be replaced by the value <tt>memory_order_relaxed</tt>. <ins>If
50502 the program does not specify an order, it shall be <tt>memory_order_seq_cst</tt>.</ins> If the operation returns <tt>true</tt>,
50503 these operations are atomic read-modify-write operations (1.10). Otherwise, these operations are atomic load operations.
50506 </p></blockquote></blockquote>
50515 <h3><a name="1475"></a>1475. [FCD] weak compare-and-exchange confusion II</h3>
50516 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50517 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-29</p>
50518 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50519 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50520 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50521 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a></p>
50522 <p><b>Discussion:</b></p>
50523 <p><b>Addresses CH-23</b></p>
50525 29.6 [atomics.types.operations] p. 23: The first sentence has non-English syntax.
50528 Resolution proposed in ballot comment:
50533 Change to "The weak compare-and-exchange
50534 operations may fail spuriously, that is, return false
50535 while leaving the contents of memory pointed to
50536 by expected unchanged."
50540 <p><b>Proposed resolution:</b></p>
50547 <h3><a name="1476"></a>1476. [FCD] Ballot Comment US-177</h3>
50548 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50549 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-07</p>
50550 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50551 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50553 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a></p>
50554 <p><b>Discussion:</b></p>
50556 <p><b>Addresses US-177</b></p>
50558 The first sentence of this paragraph doesn't make sense.
50561 Resolution proposed in ballot comment
50565 Figure out what it's supposed to say, and say it.
50569 <p><b>Proposed resolution:</b></p>
50576 <h3><a name="1477"></a>1477. [FCD] weak compare-and-exchange confusion III</h3>
50577 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
50578 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-31</p>
50579 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
50580 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
50581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
50582 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a></p>
50583 <p><b>Discussion:</b></p>
50584 <p><b>Addresses GB-135</b></p>
50586 The first sentence of 29.6 [atomics.types.operations] p.23 was changed by n2992 but
50587 now makes no sense: "that is, return <tt>false</tt> while leaving
50588 the contents of memory pointed to by <tt>expected</tt> before the
50589 operation is the same that same as that of the <tt>object</tt> and
50590 the same as that of <tt>expected</tt> after the operation."
50591 There's a minor editorial difference between n2992 ("is
50592 that same as that" vs "is the same that same as that") but
50593 neither version makes sense.
50594 Also, the remark talks about "<tt>object</tt>" which should
50595 probably be "<tt>object</tt> or <tt>this</tt>" to cover the member functions
50596 which have no object parameter.
50599 Resolution proposed in ballot comment:
50603 Fix the Remark to say whatever was intended.
50608 <p><b>Proposed resolution:</b></p>
50615 <h3><a name="1483"></a>1483. [FCD] <tt>__STDCPP_THREADS spelling</tt></h3>
50616 <p><b>Section:</b> 30.3 [thread.threads] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50617 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-26</p>
50618 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50619 <p><b>Discussion:</b></p>
50620 <p><b>Addresses DE-23</b></p>
50622 Predefined macros usually start and end with two
50623 underscores, see 16.8 and FDIS 29124 = WG21 N3060
50624 clause 7. __STDCPP_THREADS should blend in.
50627 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50633 <p><b>Proposed resolution:</b></p>
50634 Change the macro name to
50635 __STDCPP_THREADS__.
50642 <h3><a name="1484"></a>1484. [FCD] Need a way to join a thread with a timeout</h3>
50643 <p><b>Section:</b> 30.3.1 [thread.thread.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
50644 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
50646 <p><b>Discussion:</b></p>
50647 <p><b>Addresses US-183</b></p>
50649 There is no way to join a thread with a timeout.
50652 Resolution proposed by ballot comment:
50656 Add <tt>join_for</tt> and <tt>join_until</tt>. Or decide one should
50657 never join a thread with a timeout since <tt>pthread_join</tt> doesn't have a
50666 The concurrency working group deemed this an extension beyond the scope of C++0x.
50668 <p><b>Rationale:</b></p>The LWG does not wish to make a change at this time.
50672 <p><b>Proposed resolution:</b></p>
50679 <h3><a name="1488"></a>1488. [FCD] Improve interoperability between
50680 the C++0x and C1x threads APIs</h3>
50681 <p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
50682 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50683 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
50684 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
50685 <p><b>Discussion:</b></p>
50686 <p><b>Addresses US-185</b></p>
50688 Cooperate with WG14 to improve interoperability between
50689 the <tt>C++0x</tt> and <tt>C1x</tt> threads APIs. In particular, <tt>C1x</tt>
50690 mutexes should be conveniently usable with a <tt>C++0x</tt>
50691 <tt>lock_guard</tt>. Performance overheads for this combination
50692 should be considered.
50695 Resolution proposed by ballot comment:
50699 Remove <tt>C++0x</tt> <tt>timed_mutex</tt> and
50700 <tt>timed_recursive_mutex</tt> if that facilitates
50701 development of more compatible APIs.
50709 The concurrency sub-group reviewed the options, and decided that closer harmony should wait until both standards are published.
50712 <p><b>Rationale:</b></p>
50713 The LWG does not wish to make any change at this time.
50718 <p><b>Proposed resolution:</b></p>
50725 <h3><a name="1489"></a>1489. [FCD] <tt>unlock</tt> functions and unlock
50726 mutex requirements are inconsistent</h3>
50727 <p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50728 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
50729 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
50730 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50731 <p><b>Discussion:</b></p>
50732 <p><b>Addresses CH-26</b></p>
50734 Specifications of <tt>unlock</tt> member functions and <tt>unlock</tt>
50735 mutex requirements are inconsistent wrt to exceptions and
50736 pre- and postconditions.
50739 Resolution proposed by ballot comment:
50743 <tt>unlock</tt> should specifiy the precondition that the
50744 current thread "owns the lock", this will make calls
50745 without holding the locks "undefined behavior".
50746 <tt>unlock</tt> in [mutex.requirements] should either be
50747 <tt>noexcept(true)</tt> or be allowed to throw
50748 <tt>system_error</tt> like <tt>unique_lock::unlock</tt>, or the latter
50749 should be <tt>nothrow(true)</tt> and have the precondition
50750 <tt>owns == true</tt>.
50751 Furthermore <tt>unique_lock</tt>'s postcondition is wrong
50752 in the case of a recursive mutex where <tt>owns</tt>
50753 might stay true, when it is not the last <tt>unlock</tt>
50754 needed to be called.
50759 <p><b>Proposed resolution:</b></p>
50766 <h3><a name="1493"></a>1493. [FCD] Add <tt>mutex</tt>, <tt>recursive_mutex</tt>, <tt>is_locked</tt> function</h3>
50767 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
50768 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50769 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
50770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
50771 <p><b>Discussion:</b></p>
50772 <p><b>Addresses US-189</b></p>
50774 <tt>mutex</tt> and <tt>recursive_mutex</tt> should have an <tt>is_locked()</tt>
50775 member function. <tt>is_locked</tt> allows a user to test a lock
50776 without acquiring it and can be used to implement a lightweight
50777 <tt>try_try_lock</tt>.
50780 Resolution proposed by ballot comment:
50784 Add a member function:
50785 <pre>bool is_locked() const;
50787 to <tt>std::mutex</tt> and <tt>std::recursive_mutex</tt>. These
50788 functions return true if the current thread would
50789 not be able to obtain a mutex. These functions do
50790 not synchronize with anything (and, thus, can
50791 avoid a memory fence).
50799 The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x.
50802 <p><b>Rationale:</b></p>The LWG does not wish to make a change at this time.
50806 <p><b>Proposed resolution:</b></p>
50813 <h3><a name="1495"></a>1495. [FCD] Condition variable <tt>wait_for</tt> return insufficient</h3>
50814 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50815 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
50816 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
50817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50818 <p><b>Discussion:</b></p>
50819 <p><b>Addresses US-191</b></p>
50821 The condition variable <tt>wait_for</tt> returning <tt>cv_status</tt> is insufficient.
50824 Resolution proposed by ballot comment:
50828 Return a duration of timeout remaining instead.
50829 See Appendix 1 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> - Additional Details, p. 211
50834 <p><b>Proposed resolution:</b></p>
50841 <h3><a name="1496"></a>1496. [FCD] <tt>condition_variable</tt> not implementable</h3>
50842 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50843 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
50844 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
50845 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50846 <p><b>Discussion:</b></p>
50847 <p><b>Addresses CH-28</b></p>
50849 Requiring wait_until makes it impossible to implement
50850 condition_variable correctly using respective objects
50851 provided by the operating system (i.e. implementing the
50852 native_handle() function) on many platforms (e.g. POSIX,
50853 Windows, MacOS X) or using the same object as for the
50854 condition variable proposed for C.
50857 Resolution proposed by ballot comment:
50861 Remove the <tt>wait_until</tt> functions or make them at least conditionally supported.
50865 <p><b>Proposed resolution:</b></p>
50872 <h3><a name="1499"></a>1499. [FCD] Condition variables preclude wakeup optimization</h3>
50873 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Future">NAD Future</a>
50874 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
50875 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
50876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Future">NAD Future</a> status.</p>
50877 <p><b>Discussion:</b></p>
50878 <p><b>Addresses US-193</b></p>
50880 Condition variables preclude a wakeup optimization.
50883 Resolution proposed by ballot comment:
50888 Change condition_variable to allow such
50889 optimization. See Appendix 1 - Additional Details
50897 The Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x.
50900 <p><b>Rationale:</b></p>The LWG does not wish to make the change at this time.
50904 <p><b>Proposed resolution:</b></p>
50911 <h3><a name="1500"></a>1500. [FCD] Consider removal of <tt>native_handle()</tt></h3>
50912 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50913 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-28</p>
50914 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
50915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50916 <p><b>Discussion:</b></p>
50917 <p><b>Addresses CH-32</b></p>
50919 Given that the lock type can be something the underlying
50920 doesn't know 'native_handle()' is probably
50921 unimplementable on essentially all platforms.
50924 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50930 <p><b>Proposed resolution:</b></p>
50931 Consider the removal of 'native_handle()'.
50938 <h3><a name="1506"></a>1506. [FCD] set_exception with a null pointer</h3>
50939 <p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50940 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
50941 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
50942 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
50943 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50944 <p><b>Discussion:</b></p>
50945 <p><b>Addresses US-198</b></p>
50947 promise::set_exception can be called with a null pointer,
50948 but none of the descriptions of the get() functions for the
50949 three types of futures say what happens for this case.
50952 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50958 <p><b>Proposed resolution:</b></p>
50959 Add the following sentence to the end of
50960 30.6.5/22: The behavior of a program that calls
50961 set_exception with a null pointer is undefined.
50968 <h3><a name="1509"></a>1509. [FCD] No restriction on calling <tt>future::get</tt> more than once</h3>
50969 <p><b>Section:</b> 30.6.8 [futures.atomic_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
50970 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
50971 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.atomic_future">issues</a> in [futures.atomic_future].</p>
50972 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
50973 <p><b>Discussion:</b></p>
50974 <p><b>Addresses US-202</b></p>
50976 The note in this paragraph says "unlike <tt>future</tt>, calling <tt>get</tt>
50977 more than once on the same <tt>atomic_future</tt> object is well
50978 defined and produces the result again." There is nothing
50979 in <tt>future</tt> that says anything negative about calling <tt>get</tt>
50984 Resolution proposed by ballot comment:
50988 Remove this note, or add words to the
50989 requirements for future that reflect what this note
50994 <p><b>Proposed resolution:</b></p>
51001 <h3><a name="1510"></a>1510. [FCD] Should be undefined behaviour to call <tt>atomic_future</tt> operations unless <tt>valid()</tt></h3>
51002 <p><b>Section:</b> 30.6.8 [futures.atomic_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
51003 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
51004 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.atomic_future">issues</a> in [futures.atomic_future].</p>
51005 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
51006 <p><b>Discussion:</b></p>
51007 <p><b>Addresses US-203</b></p>
51009 Both <tt>future</tt> and <tt>shared_future</tt> specify that calling most
51010 member functions on an object for which <tt>valid() == false</tt>
51011 produces undefined behavior. There is no such statement
51012 for <tt>atomic_future</tt>.
51016 Resolution proposed by ballot comment:
51020 Add a new paragraph after 30.6.8 [futures.atomic_future]/2 with the same words as
51021 30.6.7 [futures.shared_future]/3.
51025 2010-11-02 Daniel translates proposed changes into specific deltas and comments:
51030 While applying the wording, I notice that 30.6.7 [futures.shared_future]/3 does
51031 speak of the move-assignment operator, and <em>not</em> of the copy-assignment operator.
51032 <tt>atomic_future</tt> obviously needs this to be true for the copy-assignment operator,
51033 but I strongly assume that <tt>shared_future</tt> needs to mention both special member
51034 assignment operators in this paragraph. To keep this consistent, the following P/R also
51035 provides wording to fix the corresponding location for <tt>shared_future</tt>.
51040 <p><b>Proposed resolution:</b></p>
51042 <li>Change 30.6.7 [futures.shared_future]/3 as indicated:
51044 3 The effect of calling any member function other than the destructor<ins>, the
51045 copy-assignment operator</ins>, the move-assignment operator, or <tt>valid()</tt>
51046 on a <tt>shared_future</tt> object for which <tt>valid() == false</tt> is undefined.
51049 <li>Following 30.6.8 [futures.atomic_future]/2, add a new paragraph:
51051 <ins>? The effect of calling any member function other than the destructor, the copy-assignment operator, or <tt>valid()</tt>
51052 on a <tt>atomic_future</tt> object for which <tt>valid() == false</tt> is undefined.</ins>
51062 <h3><a name="1511"></a>1511. [FCD] Synchronize the move-constructor for <tt>atomic_future</tt></h3>
51063 <p><b>Section:</b> 30.6.8 [futures.atomic_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
51064 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
51065 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.atomic_future">issues</a> in [futures.atomic_future].</p>
51066 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
51067 <p><b>Discussion:</b></p>
51068 <p><b>Addresses US-204</b></p>
51070 According to the definition of <tt>atomic_future</tt>, all members
51071 of <tt>atomic_future</tt> are synchronizing except constructors.
51072 However, it would probably be appropriate for a move
51073 constructor to be synchronizing on the source object. If
51074 not, the postconditions on paragraphs 7-8, might not be
51075 satisfied. This may be applicable if a collection of futures
51076 are being doled out to a set of threads that process their
51081 Resolution proposed by ballot comment:
51085 Make the move constructor for atomic future lock
51091 <p><b>Proposed resolution:</b></p>
51098 <h3><a name="1512"></a>1512. [FCD] Conflict in spec: block or join?</h3>
51099 <p><b>Section:</b> 30.6.9 [futures.async] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD Editorial">NAD Editorial</a>
51100 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
51101 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.async">issues</a> in [futures.async].</p>
51102 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
51103 <p><b>Discussion:</b></p>
51104 <p><b>Addresses US-205</b></p>
51106 30.6.9 [futures.async] p. 3: The third sentence says
51107 "If the invocation is not deferred, a call to a waiting function
51108 on an asynchronous return object that shares the associated asynchronous state
51109 created by this <tt>async</tt> call shall block until the associated
51110 thread has completed." The next sentence says "If the
51111 invocation is not deferred, the <tt>join()</tt> on the created
51112 thread..." Blocking until a thread completes is not
51113 necessarily a join.
51117 Resolution proposed by ballot comment:
51121 Decide whether the requirement is to block until
51122 finished or to call join, and rewrite to match.
51127 <p><b>Proposed resolution:</b></p>