]> rtime.felk.cvut.cz Git - l4.git/blob - l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/ext/lwg-closed.html
update
[l4.git] / l4 / pkg / libstdc++-v3 / contrib / libstdc++-v3-4.7 / doc / html / ext / lwg-closed.html
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">
6   p {text-align:justify}
7   li {text-align:justify}
8   blockquote.note
9   {
10     background-color:#E0E0E0;
11     padding-left: 15px;
12     padding-right: 15px;
13     padding-top: 1px;
14     padding-bottom: 1px;
15   }
16   ins {background-color:#A0FFA0}
17   del {background-color:#FFA0A0}
18 </style>
19 </head>
20 <body>
21 <table>
22 <tbody><tr>
23   <td align="left">Doc. no.</td>
24   <td align="left">D3183=10-0173</td>
25 </tr>
26 <tr>
27   <td align="left">Date:</td>
28   <td align="left">2010-11-29</td>
29 </tr>
30 <tr>
31   <td align="left">Project:</td>
32   <td align="left">Programming Language C++</td>
33 </tr>
34 <tr>
35   <td align="left">Reply to:</td>
36   <td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
37 </tr>
38 </tbody></table>
39 <h1>C++ Standard Library Closed Issues List (Revision D73)</h1>
40 <p>Revised 2010-11-29 at 10:11:56 UTC</p>
41
42   <p>Reference ISO/IEC IS 14882:2003(E)</p>
43   <p>Also see:</p>
44     <ul>
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>
50     </ul>
51
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
58   this document.</p>
59
60 <h2>Revision History</h2>
61 <ul>
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>
67 </ul></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>
104 </ul></li>
105 </ul>
106 </li>
107 <li>R72: 
108 2010-10-18 pre-Batavia mailing.
109 <ul>
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>
114 </ul></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>
123 </ul></li>
124 </ul>
125 </li>
126 <li>R71: 
127 2010-08-25 post-Rapperswil mailing.
128 <ul>
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>
133 </ul></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>
148 </ul></li>
149 </ul>
150 </li>
151 <li>R70: 
152 2010-03-26 post-Pittsburgh mailing.
153 <ul>
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>
158 </ul></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>
185 </ul></li>
186 </ul>
187 </li>
188 <li>R69: 
189 2010-02-12 pre-Pittsburgh mailing.
190 <ul>
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>
195 </ul></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>
221 </ul></li>
222 </ul>
223 </li>
224 <li>R68: 
225 2009-11-06 post-Santa Cruz mailing.
226 <ul>
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>
231 </ul></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>
274 </ul></li>
275 </ul>
276 </li>
277 <li>R67: 
278 2009-09-25 pre-Santa Cruz mailing.
279 <ul>
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>
284 </ul></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>
291 </ul></li>
292 </ul>
293 </li>
294 <li>R66: 
295 2009-07-31 post-Frankfurt mailing.
296 <ul>
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>
301 </ul></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>
343 </ul></li>
344 </ul>
345 </li>
346 <li>R65: 
347 2009-06-19 pre-Frankfurt mailing.
348 <ul>
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>
353 </ul></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>
373 </ul></li>
374 </ul>
375 </li>
376 <li>R64: 
377 2009-05-01 mid-term mailing.
378 <ul>
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>
383 </ul></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>
388 </ul></li>
389 </ul>
390 </li>
391 <li>R63: 
392 2009-03-20 post-Summit mailing.
393 <ul>
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>
398 </ul></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>
423 </ul></li>
424 </ul>
425 </li>
426 <li>R62: 
427 2009-02-06 pre-Summit mailing.
428 <ul>
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>
433 </ul></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>
436 </ul></li>
437 </ul>
438 </li>
439 <li>R61: 
440 2008-12-05 mid-term mailing.
441 <ul>
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>
446 </ul></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>
449 </ul></li>
450 </ul>
451 </li>
452 <li>R60: 
453 2008-10-03 post-San Francisco mailing.
454 <ul>
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>
459 </ul></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>
485 </ul></li>
486 </ul>
487 </li>
488 <li>R59: 
489 2008-08-22 pre-San Francisco mailing.
490 <ul>
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>
495 </ul></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>
498 </ul></li>
499 </ul>
500 </li>
501 <li>R58: 
502 2008-07-28 mid-term mailing.
503 <ul>
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>
508 </ul></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>
515 </ul></li>
516 </ul>
517 </li>
518 <li>R57: 
519 2008-06-27 post-Sophia Antipolis mailing.
520 <ul>
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>
525 </ul></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>
546 </ul></li>
547 </ul>
548 </li>
549 <li>R56: 
550 2008-05-16 pre-Sophia Antipolis mailing.
551 <ul>
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>
556 </ul></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>
560 </ul></li>
561 </ul>
562 </li>
563 <li>R55: 
564 2008-03-14 post-Bellevue mailing.
565 <ul>
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>
570 </ul></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>
596 </ul></li>
597 </ul>
598 </li>
599 <li>R54: 
600 2008-02-01 pre-Bellevue mailing.
601 <ul>
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>
606 </ul></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>
614 </ul></li>
615 </ul>
616 </li>
617 <li>R53: 
618 2007-12-09 mid-term mailing.
619 <ul>
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>
624 </ul></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>
629 </ul></li>
630 </ul>
631 </li>
632 <li>R52: 
633 2007-10-19 post-Kona mailing.
634 <ul>
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>
639 </ul></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>
654 </ul></li>
655 </ul>
656 </li>
657 <li>R51: 
658 2007-09-09 pre-Kona mailing.
659 <ul>
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>
664 </ul></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>
667 </ul></li>
668 </ul>
669 </li>
670 <li>R50: 
671 2007-08-05 post-Toronto mailing.
672 <ul>
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>
677 </ul></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>
694 </ul></li>
695 </ul>
696 </li>
697 <li>R49: 
698 2007-06-23 pre-Toronto mailing.
699 <ul>
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>
704 </ul></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>
711 </ul></li>
712 </ul>
713 </li>
714 <li>R48: 
715 2007-05-06 post-Oxford mailing.
716 <ul>
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>
721 </ul></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>
738 </ul></li>
739 </ul>
740 </li>
741 <li>R47: 
742 2007-03-09 pre-Oxford mailing.
743 <ul>
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>
748 </ul></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>
756 </ul></li>
757 </ul>
758 </li>
759 <li>R46: 
760 2007-01-12 mid-term mailing.
761 <ul>
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>
766 </ul></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>
769 </ul></li>
770 </ul>
771 </li>
772 <li>R45: 
773 2006-11-03 post-Portland mailing.
774 <ul>
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>
779 </ul></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>
788 </ul></li>
789 </ul>
790 </li>
791 <li>R44: 
792 2006-09-08 pre-Portland mailing.
793 <ul>
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>
798 </ul></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>
801 </ul></li>
802 </ul>
803 </li>
804 <li>R43: 
805 2006-06-23 mid-term mailing.
806 <ul>
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>
811 </ul></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>
816 </ul></li>
817 </ul>
818 </li>
819 <li>R42: 
820 2006-04-21 post-Berlin mailing.
821 <ul>
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>
826 </ul></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>
834 </ul></li>
835 </ul>
836 </li>
837 <li>R41: 
838 2006-02-24 pre-Berlin mailing.
839 <ul>
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>
844 </ul></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>
849 </ul></li>
850 </ul>
851 </li>
852 <li>R40: 
853 2005-12-16 mid-term mailing.
854 <ul>
855 <li><b>Summary:</b><ul>
856 <li>95 open issues.</li>
857 <li>440 closed issues.</li>
858 <li>535 issues total.</li>
859 </ul></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>
862 </ul></li>
863 </ul>
864 </li>
865 <li>R39: 
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.
874 </li>
875 <li>R38: 
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>
879 </li>
880 <li>R37: 
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>.
883 </li>
884 <li>R36: 
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".
888 </li>
889 <li>R35: 
890 2005-03 pre-Lillehammer mailing.
891 </li>
892 <li>R34: 
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>.
894 </li>
895 <li>R33: 
896 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
897 </li>
898 <li>R32: 
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>.
902 </li>
903 <li>R31: 
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>.
907 </li>
908 <li>R30: 
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>.
912 </li>
913 <li>R29: 
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>.
915 </li>
916 <li>R28: 
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>.
919 </li>
920 <li>R27: 
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>.
922 </li>
923 <li>R26: 
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.
927 </li>
928 <li>R25: 
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>.
930 </li>
931 <li>R24: 
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>
938 <li>R23: 
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.
941 </li>
942 <li>R22: 
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">.
944 </iref></li>
945 <li>R21: 
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">.
947 </iref></li>
948 <li>R20: 
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.  
953
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>.
956
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>.
960 </li>
961 <li>R19: 
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>.
964 </li>
965 <li>R18: 
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>.
969
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>
978 to DR.
979
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>
990 to Ready.
991
992 Closed issues 
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>
996 as NAD.
997
998 </li>
999 <li>R17: 
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>.
1003 </iref></li>
1004 <li>R16:  
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.
1025 </li>
1026 <li>R15: 
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.
1030 </li>
1031 <li>R14: 
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)
1034 </li>
1035 <li>R13: 
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>.
1037 </li>
1038 <li>R12: 
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>.
1043 </li>
1044 <li>R11: 
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>.
1052 </li>
1053 <li>R10: 
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)
1058 </li>
1059 <li>R9: 
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)
1063 </li>
1064 <li>R8: 
1065 post-Dublin mailing. Updated to reflect LWG and full committee actions
1066 in Dublin. (99-0016/N1193, 21 Apr 99)
1067 </li>
1068 <li>R7: 
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)
1073 </li>
1074 <li>R6: 
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)
1077 </li>
1078 <li>R5: 
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)
1082 </li>
1083 <li>R4: 
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)
1087 </li>
1088 <li>R3: 
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)
1091 </li>
1092 <li>R2: 
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)
1095 </li>
1096 <li>R1: 
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)
1099 </li>
1100 </ul>
1101
1102 <h2>Closed Issues</h2>
1103 <hr>
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-&gt;release()" where it clearly must be "Calls
1111 p.release()". (As it is, it seems to require using
1112 auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
1113 exists.)</p>
1114
1115
1116 <p><b>Proposed resolution:</b></p>
1117 <p>Change 20.7.4.3 [meta.unary.prop] paragraph 1 Effects from 
1118 "Calls p-&gt;release()" to "Calls p.release()".</p>
1119
1120
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>
1124
1125
1126
1127
1128
1129 <hr>
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>
1140
1141
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>
1148
1149
1150
1151
1152
1153 <hr>
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&lt;&gt; 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>
1169
1170
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>
1174
1175
1176
1177
1178
1179 <hr>
1180 <h3><a name="10"></a>10. Codecvt&lt;&gt;::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&lt;&gt;::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
1193 intended here. </p>
1194
1195
1196 <p><b>Rationale:</b></p>
1197
1198
1199
1200
1201
1202
1203 <hr>
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>
1215
1216 <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
1217 unspecified? </p>
1218
1219
1220 <p><b>Rationale:</b></p>
1221 <p>Not a defect. The LWG believes that the Standard is already
1222 clear.&nbsp; See 23.2 [container.requirements], paragraph 8.</p>
1223
1224
1225
1226
1227
1228 <hr>
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>
1236
1237
1238 <p><b>Rationale:</b></p>
1239
1240
1241
1242
1243
1244
1245 <hr>
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>
1252
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&nbsp; read pointers of a stringstream should
1256 be."</p>
1257
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>
1260
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>
1264
1265
1266
1267
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>
1273
1274
1275
1276
1277
1278 <hr>
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&lt;charT, Traits&gt;</tt>. </p>
1289
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
1293 conversion. </p>
1294
1295
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>
1299
1300
1301
1302
1303 <hr>
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
1313 get/put area. </p>
1314
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.)
1318 </p>
1319
1320
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>
1324
1325
1326
1327
1328
1329 <hr>
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>
1339
1340 <pre>   string text("Hello");
1341    cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
1342 </pre>
1343
1344 <p>Shouldn't it be:</p>
1345
1346 <pre>   [     Hello]</pre>
1347
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.)
1354 </p>
1355
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>
1359
1360
1361 <p><b>Rationale:</b></p>
1362
1363
1364
1365
1366
1367
1368 <hr>
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
1379 contexts above.</p>
1380
1381
1382 <p><b>Rationale:</b></p>
1383
1384
1385
1386
1387
1388 <hr>
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>
1399
1400
1401 <p><b>Rationale:</b></p>
1402 <p>Not a defect. This is a deliberate feature; const streams would be
1403 meaningless.</p>
1404
1405
1406
1407
1408 <hr>
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>
1416 <p>valarray:<br>
1417 <br>
1418 &nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
1419 <br>
1420 why not <br>
1421 <br>
1422 &nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
1423 <br>
1424 as in vector ???<br>
1425 <br>
1426 One can't copy even from a const valarray eg:<br>
1427 <br>
1428 &nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
1429 </tt><br>
1430 [I] find this bug in valarray is very difficult.</p>
1431
1432
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>
1442
1443
1444
1445
1446
1447 <hr>
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 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
1456
1457 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;); 
1458 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
1459
1460 <p>IMHO they have to be</p>
1461
1462 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;); 
1463 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
1464
1465 <p>Same for gslice_array. </p>
1466
1467
1468 <p><b>Rationale:</b></p>
1469 <p>Not a defect. The Standard is correct as written. </p>
1470
1471
1472
1473
1474 <hr>
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>
1483
1484 <blockquote><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&lt;const Key, T&gt;.  
1487 </p></blockquote>
1488
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>
1491
1492
1493 <p><b>Rationale:</b></p>
1494 <p>Not a defect. The Standard is correct as written; it uses a
1495 different mechanism (const &amp;) 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
1497 issue.</p>
1498
1499
1500
1501
1502 <hr>
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>
1508 <p>If I try</p>
1509 <pre>    s.insert(0,1,' ');</pre>
1510
1511 <p>&nbsp; I get an nasty ambiguity. It might be</p>
1512 <pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
1513
1514 <p>which inserts 1 space character at position 0, or</p>
1515 <pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>
1516
1517 <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
1518 <pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
1519
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>
1524
1525
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>
1530
1531
1532
1533
1534 <hr>
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>
1544
1545
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>
1549
1550
1551
1552
1553 <hr>
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>
1562
1563 <pre>int compare(size_type pos, size_type n1, 
1564             charT *s, size_type n2 = npos) const;
1565 </pre>
1566
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
1569 exception) </p>
1570
1571
1572 <p><b>Rationale:</b></p>
1573
1574
1575
1576
1577
1578 <hr>
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>
1585 <p>Why does </p>
1586 <pre>  template&lt;class InputIterator&gt; 
1587        basic_string&amp; append(InputIterator first, InputIterator last);</pre>
1588
1589 <p>return a string, while</p>
1590 <pre>  template&lt;class InputIterator&gt; 
1591        void insert(iterator p, InputIterator first, InputIterator last);</pre>
1592
1593 <p>returns nothing ?</p>
1594
1595
1596 <p><b>Rationale:</b></p>
1597 <p>The LWG believes this stylistic inconsistency is not sufficiently 
1598 serious to constitute a defect.</p>
1599
1600
1601
1602
1603 <hr>
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
1614 maximum. </p>
1615
1616
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>
1620
1621
1622
1623
1624
1625 <hr>
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
1636 valarrays. </p>
1637
1638 <p>For example, to multiply two subsets and assign the result to a third subset, you can't
1639 write the following:</p>
1640
1641 <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
1642
1643 <p>Instead, you have to code as follows:</p>
1644
1645 <pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) * 
1646                    static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
1647
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>
1650
1651
1652 <p><b>Proposed resolution:</b></p>
1653 <p>Extend all valarray subset types so that they offer all valarray operations.</p>
1654
1655
1656 <p><b>Rationale:</b></p>
1657 <p>This is not a defect in the Standard; it is a request for an extension.</p>
1658
1659
1660
1661
1662 <hr>
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 &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
1671 vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
1672 int N = 1&gt; class vector;</tt> </p>
1673
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
1677 forbidden. </p>
1678
1679 <p>comment from Steve Cleary via comp.std.c++:</p>
1680 <blockquote>
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>
1695 <pre> 
1696    template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
1697    class __vector
1698    { ... };
1699    template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
1700    class vector: public __vector&lt;T, Allocator&gt;
1701    { ... };
1702 </pre>
1703
1704 </blockquote>
1705
1706
1707
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>
1710
1711 <blockquote>
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>
1717 </blockquote>
1718
1719 <p>Add "template parameters" to the list of subclauses at
1720 the end of 17.6.4 [conforming] paragraph 1.</p>
1721
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>
1727
1728
1729
1730
1731 <p><b>Rationale:</b></p>
1732 <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 
1738 standard.
1739 </p>
1740
1741 <p>
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.
1745 </p>
1746
1747
1748
1749
1750
1751 <hr>
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>
1759
1760 <p>Example: </p>
1761
1762 <blockquote>
1763   <pre>// implementation code:
1764 struct _Base { // _Base is in the implementer namespace
1765         virtual void foo ();
1766 };
1767 class vector : _Base // deriving from a class is allowed
1768 { ... };
1769
1770 // user code:
1771 class vector_checking : public vector 
1772 {
1773         void foo (); // don't want to override _Base::foo () as the 
1774                      // user doesn't know about _Base::foo ()
1775 };</pre>
1776 </blockquote>
1777
1778
1779 <p><b>Proposed resolution:</b></p>
1780 <p>Clarify the wording to make the example illegal.</p>
1781
1782
1783 <p><b>Rationale:</b></p>
1784 <p>This is not a defect in the Standard.&nbsp; The example is already
1785 illegal.&nbsp; See 17.6.4.5 [member.functions] paragraph 2.</p>
1786
1787
1788
1789
1790 <hr>
1791 <h3><a name="96"></a>96. Vector&lt;bool&gt; 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&lt;bool&gt;</tt> is not a container as its reference and
1798 pointer types are not references and pointers. </p>
1799
1800 <p>Also it forces everyone to have a space optimization instead of a
1801 speed one.</p>
1802
1803 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
1804 Nonconforming, Forces Optimization Choice.</p>
1805
1806 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
1807
1808
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>
1812
1813
1814 <p><i>[The LWG looked at the following resolutions in some detail:
1815 <br>
1816 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
1817 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
1818 Container requirements.<br>
1819 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
1820 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
1821 vector&lt;bool&gt; would meet.<br>
1822 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
1823 <br>
1824 No alternative had strong, wide-spread, support and every alternative
1825 had at least one "over my dead body" response.<br>
1826 <br>
1827 There was also mention of a transition scheme something like (1) add
1828 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
1829 Remove vector&lt;bool&gt; in the following standard.]</i></p>
1830
1831
1832 <p><i>[Modifying container requirements to permit returning proxies
1833 (thus allowing container requirements conforming vector&lt;bool&gt;)
1834 was also discussed.]</i></p>
1835
1836
1837 <p><i>[It was also noted that there is a partial but ugly workaround in
1838 that vector&lt;bool&gt; may be further specialized with a customer
1839 allocator.]</i></p>
1840
1841
1842 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1843 vector&lt;bool&gt;: 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>
1849
1850
1851 <p>Discussed at Lillehammer.  General agreement that we should
1852   deprecate vector&lt;bool&gt; and introduce this functionality under
1853   a different name, e.g. bit_vector.  This might make it possible to
1854   remove the vector&lt;bool&gt; 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&lt;bool&gt; refers to the specialization or to the
1858   primary template, but there wasn't general agreement that this was a
1859   good idea.</p>
1860
1861 <p>We need a paper for the new bit_vector class.</p>
1862
1863 <p><i>[
1864 Batavia:
1865 ]</i></p>
1866
1867 <blockquote>
1868 The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1869 from <tt>vector&lt;bool&gt;</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.
1873 </blockquote>
1874
1875 <p><i>[
1876 Post Summit Alisdair adds:
1877 ]</i></p>
1878
1879
1880 <blockquote>
1881 <p>
1882 <tt>vector&lt;bool&gt;</tt> is now a conforming container under the revised terms of C++0x,
1883 which supports containers of proxies.
1884 </p>
1885 <p>
1886 Recommend NAD.
1887 </p>
1888 <p>
1889 Two issues remain:
1890 </p>
1891 <p>
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.
1896 </p>
1897 <p>
1898 Recommend: Create a new issue for the discussion, leave as Open.
1899 </p>
1900 <p>
1901 ii/ Request for a new bitvector class to guarantee the optimization, perhaps
1902 with a better tuned interface.
1903 </p>
1904 <p>
1905 This is a clear extension request that may be handled via a future TR.
1906 </p>
1907 </blockquote>
1908
1909 <p><i>[
1910 Batavia (2009-05):
1911 ]</i></p>
1912
1913 <blockquote>
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).
1917 </blockquote>
1918
1919 <p><i>[
1920 2009-07-29 Alisdair reopens:
1921 ]</i></p>
1922
1923
1924 <blockquote>
1925 <p>
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.
1932 </p>
1933
1934 <p>
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.
1938 </p>
1939 </blockquote>
1940
1941 <p><i>[
1942 2009-10 Santa Cruz:
1943 ]</i></p>
1944
1945
1946 <blockquote>
1947 Mark as NAD, and give rationale.
1948 </blockquote>
1949
1950
1951
1952 <p><b>Proposed resolution:</b></p>
1953 <p>
1954 We now have:
1955 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1956 and
1957 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1958 </p>
1959
1960
1961
1962 <p><b>Rationale:</b></p>
1963 <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.
1968 </p>
1969 <p>
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.
1974 </p>
1975
1976
1977
1978
1979
1980 <hr>
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&amp;)</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>
1991
1992
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>
1996
1997
1998
1999
2000 <hr>
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 &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
2007 return the opposite of what they should.</p>
2008
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>
2012
2013
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>
2018
2019
2020
2021
2022 <hr>
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>
2033
2034
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>
2039
2040
2041
2042
2043
2044 <hr>
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>
2052
2053 <p><i>[
2054 2010-02-13 Alisdair adds:
2055 ]</i></p>
2056
2057
2058 <blockquote>
2059 <p>
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
2061 this action.
2062 </p>
2063 </blockquote>
2064
2065
2066
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&lt;T&gt;</tt>):
2073 </p>
2074
2075 <blockquote>
2076   <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
2077 </blockquote>
2078
2079
2080
2081
2082
2083 <hr>
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>
2095
2096
2097 <p><b>Proposed resolution:</b></p>
2098 <p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
2099
2100
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>
2103
2104
2105
2106
2107
2108 <hr>
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>
2117
2118
2119 <p><b>Proposed resolution:</b></p>
2120 <p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
2121 the non-const version is used, then the behavior is undefined.</p>
2122
2123
2124 <p><b>Rationale:</b></p>
2125 <p>The Standard is correct. The proposed resolution already appears in
2126 the Standard.</p>
2127
2128
2129
2130
2131 <hr>
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>
2138
2139
2140 <p>fstream ctors take a const char* instead of string.<br>
2141 fstream ctors can't take wchar_t</p>
2142
2143 <p>An extension to add a const wchar_t* to fstream would make the
2144 implementation non conforming.</p>
2145
2146
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>
2150
2151
2152
2153
2154 <hr>
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>
2165
2166
2167 <p><b>Proposed resolution:</b></p>
2168 <p>Inverting the arguments could silently break programs. Introduce
2169 the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
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
2172 containers.</p>
2173
2174
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&lt;size_t&gt; and
2179 perhaps other cases.</p>
2180
2181
2182
2183
2184 <hr>
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&lt;&gt;::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>
2196
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>
2202
2203 <p>The solution is to weaken the requirement on the function to return
2204 true only if both iterators are at eof. </p>
2205
2206 <p><i>[
2207 Summit:
2208 ]</i></p>
2209
2210
2211 <blockquote>
2212 Reopened by Alisdair.
2213 </blockquote>
2214
2215 <p><i>[
2216 Post Summit Daniel adds:
2217 ]</i></p>
2218
2219
2220 <blockquote>
2221 <p>
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:
2226 </p>
2227
2228 <blockquote>
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.
2232 </blockquote>
2233
2234 <p><i>[
2235 2009-07 Frankfurt
2236 ]</i></p>
2237
2238
2239 <blockquote>
2240 Agree NAD.
2241 </blockquote>
2242
2243 </blockquote>
2244
2245
2246
2247 <p><b>Proposed resolution:</b></p>
2248 <p>Replace 24.6.3.5 [istreambuf.iterator::equal],
2249 paragraph 1, </p>
2250
2251 <blockquote>
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>
2254 </blockquote>
2255
2256 <p>with</p>
2257
2258 <blockquote>
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>
2261 </blockquote>
2262
2263
2264
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>
2271
2272
2273
2274
2275
2276 <hr>
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,
2284 paragraph 36. </p>
2285
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>
2289
2290 <p>The sync function should at minimum be added to basic_ostream, for internal
2291 consistency. </p>
2292
2293 <p>A larger question is whether sync should have assigned semantics for input streams. </p>
2294
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
2299 strstream. </p>
2300
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>
2303
2304
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>
2308
2309 <p>As for the other points, the LWG finds the standard correct as written.</p>
2310
2311
2312
2313
2314
2315 <hr>
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>
2323
2324
2325
2326 <p>The following code does not compile with the EDG compiler:</p>
2327
2328 <blockquote>
2329   <pre>#include &lt;bitset&gt;
2330 using namespace std;
2331 bitset&lt;32&gt; b("111111111");</pre>
2332 </blockquote>
2333
2334 <p>If you cast the ctor argument to a string, i.e.:</p>
2335
2336 <blockquote>
2337   <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
2338 </blockquote>
2339
2340 <p>then it will compile. The reason is that bitset has the following templatized
2341 constructor:</p>
2342
2343 <blockquote>
2344   <pre>template &lt;class charT, class traits, class Allocator&gt;
2345 explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
2346 </blockquote>
2347
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."
2354 </p>
2355
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
2358 longer work.</p>
2359
2360
2361 <p><b>Proposed resolution:</b></p>
2362 <p>Add to 20.5 [template.bitset] a bitset constructor declaration</p>
2363
2364 <blockquote>
2365   <pre>explicit bitset(const char*);</pre>
2366 </blockquote>
2367
2368 <p>and in Section 20.5.1 [bitset.cons] add:</p>
2369
2370 <blockquote>
2371   <pre>explicit bitset(const char* str);</pre>
2372   <p>Effects: <br>
2373   &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
2374 </blockquote>
2375
2376
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
2381 extension.</p>
2382
2383
2384
2385
2386
2387 <hr>
2388 <h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; 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&lt;char&gt; ,
2395 ctype&lt;wchar_t&gt;. </p>
2396
2397 <p>Also Section 22.4.1.1 [locale.ctype] says: </p>
2398
2399 <blockquote>
2400   <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
2401   ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
2402   native character set. </p>
2403 </blockquote>
2404
2405 <p>However, Section 22.4.1.3 [facet.ctype.special]
2406 only has a detailed description of the ctype&lt;char&gt; specialization, not the
2407 ctype&lt;wchar_t&gt; specialization. </p>
2408
2409
2410 <p><b>Proposed resolution:</b></p>
2411 <p>Add the ctype&lt;wchar_t&gt; detailed class description to Section 
2412 22.4.1.3 [facet.ctype.special]. </p>
2413
2414
2415 <p><b>Rationale:</b></p>
2416 <p>Specialization for wchar_t is not needed since the default is acceptable.</p>
2417
2418
2419
2420
2421
2422 <hr>
2423 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; 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>
2430
2431 <blockquote>
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 &lt;&lt; or operator
2435   &gt;&gt; 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>
2439 </blockquote>
2440
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>
2444
2445 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
2446 current open mode setting. </p>
2447
2448 <p><i>[
2449 post Bellevue:  Alisdair requested to re-Open.
2450 ]</i></p>
2451
2452
2453 <p><i>[
2454 2009-07 Frankfurt
2455 ]</i></p>
2456
2457
2458 <blockquote>
2459 <p>
2460 Neither Howard nor Bill has received a customer request for this.
2461 </p>
2462 <p>
2463 No consensus for change. The programmer can save this information to the side.
2464 </p>
2465 <p>
2466 Moved to NAD.
2467 </p>
2468 </blockquote>
2469
2470
2471
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>
2475
2476 <p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
2477
2478 <p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
2479
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&lt;&gt;::init()</tt>.</p>
2486
2487
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>
2492
2493
2494
2495
2496
2497 <hr>
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>
2506
2507
2508 <p><b>Rationale:</b></p>
2509 <p>Size() cannot grow beyond max_size().&nbsp; </p>
2510
2511
2512
2513
2514
2515 <hr>
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&lt;charT,traits&gt;(sb) (lib.istream) and
2524 basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
2525
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>
2529
2530
2531 <p><b>Proposed resolution:</b></p>
2532 <p>Change 27.6.1.5.1, paragraph 1 to:</p>
2533
2534 <p>-1- Effects Constructs an object of class basic_iostream, assigning
2535 initial values to the base classes by calling
2536 basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
2537
2538
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
2542 standard.</p>
2543
2544
2545
2546
2547 <hr>
2548 <h3><a name="138"></a>138. Class ctype_byname&lt;char&gt; 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&lt;char&gt; must be a specialization of the ctype_byname
2556 template.</p>
2557
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>
2563
2564 <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
2565 fact, that ctype_byname&lt;char&gt; 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>
2569
2570 <p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
2571 specialization, because the base class ctype&lt;char&gt; 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>
2574
2575 <p><i>[
2576 Summit:
2577 ]</i></p>
2578
2579
2580 <blockquote>
2581 Reopened by Alisdair.
2582 </blockquote>
2583
2584 <p><i>[
2585 2009-07 Frankfurt
2586 ]</i></p>
2587
2588
2589 <blockquote>
2590 Moved to NAD.
2591 </blockquote>
2592
2593
2594
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>
2599
2600
2601
2602
2603 <hr>
2604 <h3><a name="140"></a>140. map&lt;Key, T&gt;::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>
2610 <blockquote>
2611   <p>23.2 [container.requirements]<br>
2612   <br>
2613   expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
2614   &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
2615   -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
2616   -------------------<br>
2617   X::value_type&nbsp;&nbsp;&nbsp; T
2618   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2619   T is assignable<br>
2620   <br>
2621   23.6.1 [map]<br>
2622   <br>
2623   A map satisfies all the requirements of a container.<br>
2624   <br>
2625   For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
2626 </blockquote>
2627
2628 <p>There's a contradiction here. In particular, `pair&lt;const Key,
2629 T&gt;' is not assignable; the `const Key' cannot be assigned
2630 to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
2631 assignable requirement imposed by a container.</p>
2632
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>
2635
2636
2637
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>
2642
2643
2644
2645
2646 <hr>
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>
2653
2654 <blockquote>
2655
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>
2661
2662 </blockquote>
2663
2664 <p>I think it should mention the global name space somewhere...&nbsp;
2665 Currently, it indicates that name placed in std is also placed in
2666 std...</p>
2667
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>
2672
2673 <blockquote>
2674   <pre>// version 1:
2675 namespace std {
2676         struct tm { ... };
2677 }
2678 using std::tm;
2679
2680 // version 2:
2681 struct tm { ... };
2682 namespace std {
2683         using ::tm;
2684 }
2685
2686 // version 3:
2687 struct tm { ... };
2688 namespace std {
2689         struct tm { ... };
2690 }</pre>
2691 </blockquote>
2692
2693 <p>I think version 1 is intended.</p>
2694
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>
2700
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
2703 (2):</i></p>
2704
2705 <blockquote>
2706   <ul>
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>
2710   </ul>
2711 </blockquote>
2712
2713 <p><i>]</i></p>
2714
2715 <p><b>Example:</b></p>
2716
2717 <blockquote>
2718
2719 <pre>#include &lt;time.h&gt;
2720 #include &lt;utility&gt;
2721
2722 int main() {
2723     std::tm * t;
2724     make_pair( t, t ); // okay with version 1 due to Koenig lookup
2725                        // fails with version 2; make_pair not found
2726     return 0;
2727 }</pre>
2728
2729 </blockquote>
2730
2731
2732 <p><b>Proposed resolution:</b></p>
2733
2734 <p>Replace D.7 [depr.c.headers] paragraph 2 with:</p>
2735
2736 <blockquote>
2737
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>
2743
2744 </blockquote>
2745
2746
2747
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>
2754
2755
2756
2757
2758 <hr>
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>
2771
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>
2778
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>
2782
2783
2784
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>
2788
2789
2790
2791
2792 <hr>
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>
2808
2809
2810 <p><b>Rationale:</b></p>
2811
2812
2813
2814
2815
2816 <hr>
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>
2833
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
2835 output</p>
2836
2837
2838 <p><b>Rationale:</b></p>
2839
2840
2841
2842
2843
2844 <hr>
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>
2869
2870
2871 <p><b>Rationale:</b></p>
2872
2873
2874
2875
2876
2877 <hr>
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> 
2887
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>
2890
2891
2892 <p><b>Rationale:</b></p>
2893
2894
2895
2896
2897
2898 <hr>
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 &lt;class Iterator&gt; 
2913 struct iterator_traits
2914 {
2915     typedef typename Iterator::value_type value_type;
2916 };
2917
2918 template &lt;class T&gt; class reverse_iterator;
2919
2920 // reverse_iterator operator+
2921 template &lt;class T&gt; 
2922 reverse_iterator&lt;T&gt; operator+
2923 (typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
2924
2925 template &lt;class T&gt; struct complex {};
2926
2927 // complex operator +
2928 template &lt;class T&gt;
2929 complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs) 
2930 { return complex&lt;T&gt;();} 
2931 }
2932
2933 // request for explicit instantiation
2934 template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;, 
2935      const std::complex&lt;float&gt;&amp;);</pre>
2936 <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2937
2938
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+&lt;float&gt;" to
2944 "std::operator+".</p>
2945
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
2950 syntax.</p>
2951
2952
2953
2954
2955 <hr>
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>
2962 <p>
2963 Section 27.3.1 says "After the object cerr is initialized,
2964 cerr.flags() &amp; 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).
2969 </p>
2970 <p>
2971 Neither of the popular standard library implementations
2972 that I tried does this, they both tie cerr and clog
2973 to &amp;cout. I would think that would be what users expect.
2974 </p>
2975
2976
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 &amp; 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>
2984
2985
2986
2987
2988 <hr>
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&lt;T&gt;::op=(const T&amp;), but fails to provide
2997 corresponding versions for the helper classes. Thus making the
2998 following illegal:</p>
2999 <blockquote>
3000 <pre>#include &lt;valarray&gt;
3001
3002 int main()
3003 {
3004 std::valarray&lt;double&gt; v(3.14, 1999);
3005
3006 v[99] *= 2.0; // Ok
3007
3008 std::slice s(0, 50, 2);
3009
3010 v[s] *= 2.0; // ERROR
3011 }</pre>
3012 </blockquote>
3013 <p>I can't understand the intent of that omission.  It makes the
3014 valarray library less intuitive and less useful.</p>
3015
3016
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.&nbsp; A future standard may wish to add the missing
3021 operators.</p>
3022
3023
3024
3025
3026 <hr>
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>
3037 <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>
3040
3041 <p><i>[
3042 post Bellevue:  Alisdair requested to re-Open.
3043 ]</i></p>
3044
3045
3046 <p><i>[
3047 2009-07 Frankfurt
3048 ]</i></p>
3049
3050
3051 <blockquote>
3052 <p>
3053 C++0x has lambdas to address this problem now.
3054 </p>
3055 <p>
3056 Moved to NAD.
3057 </p>
3058 </blockquote>
3059
3060
3061
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.&nbsp; A future standard may wish to consider additional
3065 function objects.</p>
3066
3067
3068
3069
3070 <hr>
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().&nbsp;<br>
3084 <br>
3085 However, strictly speaking the standard contains no bug here. So this
3086 might considered to be a clarification or improvement.
3087 </p>
3088
3089
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
3094 iterators.</p>
3095
3096
3097
3098
3099 <hr>
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">
3111   <tbody><tr>
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>
3116   </tr>
3117   <tr>
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>
3125   </tr>
3126 </tbody></table>
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>
3145
3146
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">
3151   <tbody><tr>
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>
3156   </tr>
3157   <tr>
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>
3165   </tr>
3166   <tr>
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
3171       ordering.</td>
3172     <td>logarithmic in general, but amortized constant if t is inserted right
3173       before p.</td>
3174   </tr>
3175 </tbody></table>
3176
3177
3178
3179 <p><b>Rationale:</b></p>
3180 <p>Too big a change.&nbsp; Furthermore, implementors report checking
3181 both before p and after p, and don't want to change this behavior.</p>
3182
3183
3184
3185
3186
3187 <hr>
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>
3217 <blockquote>
3218   <pre> filebuf mybuf;
3219  fstream f;
3220  f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
3221 </blockquote>
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>
3226
3227
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>
3233
3234 <p>Permission is not required to add such an extension.  See 
3235 17.6.4.5 [member.functions].</p>
3236
3237
3238
3239
3240 <hr>
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>
3249
3250 <blockquote>
3251
3252 <p>[Example: This can be useful for constructing an object at a known address:<br>
3253 <br>
3254 <tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
3255 &nbsp;&nbsp; Something* p = new (place) Something();<br>
3256 <br>
3257 </tt>end example] </p>
3258
3259 </blockquote>
3260
3261 <p>This example has potential alignment problems. </p>
3262
3263
3264 <p><b>Rationale:</b></p>
3265
3266
3267
3268
3269
3270 <hr>
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>
3278
3279 <p>Must the value returned from max_size() be meaningful? </p>
3280
3281 <p>Possible meanings identified in lib-6827: </p>
3282
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>
3288 <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
3294 compile time.<br>
3295 <br>
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>
3300 <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
3306 called. </p>
3307
3308
3309 <p><b>Proposed resolution:</b></p>
3310
3311
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>
3317
3318 <p>It is clear to the LWG that the value returned by max_size() can't
3319   change from call to call.</p>
3320
3321
3322
3323
3324
3325
3326 <hr>
3327 <h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</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>
3334 <blockquote>
3335   <p>To decide if the character c is a whitespace character, the constructor      
3336      performs ''as if'' it executes the following code fragment:&nbsp;</p>
3337   <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
3338 if (ctype.is(ctype.space,c)!=0)
3339 // c is a whitespace character.</pre>
3340 </blockquote>
3341
3342 <p> But Table 51 in 22.1.1.1.1 only requires an implementation to
3343 provide specializations for ctype&lt;char&gt; and
3344 ctype&lt;wchar_t&gt;.  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&lt;charT&gt; specialization
3348 for an arbitrary charT) definitions of ctype's virtual member
3349 functions.</p>
3350
3351 <p>
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.
3359 </p>
3360
3361 <p> 
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:
3365 </p>
3366
3367 <blockquote><p>
3368 An implementation is forbidden from using the above code if it renders
3369 the constructor uninstantiable for an otherwise valid character
3370 type.
3371 </p></blockquote>
3372
3373 <p>In any event, some clarification is needed.</p>
3374
3375
3376
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>
3381
3382
3383
3384
3385 <hr>
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
3399 - first".</p>
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
3418 category?</p>
3419
3420
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
3424 the standard.</p>
3425
3426
3427
3428
3429 <hr>
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
3439 provided.</p>
3440
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
3445 unclear.</p>
3446
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>
3452
3453
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>
3457
3458
3459
3460
3461 <hr>
3462 <h3><a name="207"></a>207. ctype&lt;char&gt; 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>
3469 <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.
3474 </p>
3475
3476
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>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
3481
3482 <p>to:</p>
3483 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
3484 respectively.</p>
3485
3486 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
3487 from:</p> 
3488 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
3489
3490 <p>to:</p>
3491 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to), 
3492 respectively.</p>
3493
3494
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
3497 paragraphs.</p>
3498
3499
3500
3501
3502
3503
3504 <hr>
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>
3519
3520
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>
3526
3527
3528
3529
3530 <hr>
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&lt;const int&gt; is
3540 not legal, I think:</p>
3541 <blockquote>
3542   <pre>map &lt; const int, ... &gt; // legal?</pre>
3543 </blockquote>
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>
3546 <blockquote>
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
3552 too.</p>
3553 </blockquote>
3554
3555
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>
3559
3560
3561
3562
3563 <hr>
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>
3572 <blockquote>
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&lt;&lt;s behaves
3576 as if f(s) were called, in is an (instance of) basic_istream then the
3577 expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
3578 defined as:</p>
3579 <pre>ios_base&amp; f(ios_base&amp; str, int base)
3580 {
3581   // set basefield
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);
3586   return str;
3587 }</pre>
3588 </blockquote>
3589 <p>There are two problems here. First, f takes two parameters, so the
3590 description needs to say that out&lt;&lt;s and in&gt;&gt;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>
3598
3599
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>
3603
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>
3606
3607
3608
3609
3610
3611
3612
3613
3614 <hr>
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&lt;.</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&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
3629 the use of operator&lt;, would cause the following innocent-looking code to have
3630 undefined behavior:</p>
3631 <blockquote>
3632   <pre>vector&lt;string*&gt; vec;
3633 sort(vec.begin(), vec.end());</pre>
3634 </blockquote>
3635 <p>The use of operator&lt; is not defined for pointers to unrelated objects. If
3636 std::sort used less&lt;&gt; to compare elements, then the above code would be
3637 well-defined, since less&lt;&gt; is explicitly specialized to produce a total
3638 ordering of pointers.</p>
3639
3640
3641 <p><b>Rationale:</b></p>
3642 <p>This use of operator== and operator&lt; 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
3645 operator&lt;.</p>
3646
3647
3648
3649
3650 <hr>
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>
3664
3665 <p><i>[
3666 Summit:
3667 ]</i></p>
3668
3669
3670 <blockquote>
3671 Reopened by Alisdair.
3672 </blockquote>
3673
3674 <p><i>[
3675 2009-07 Frankfurt
3676 ]</i></p>
3677
3678
3679 <blockquote>
3680 <p>
3681 The same thing can be achieved using find_if (as noted in the issue).
3682 </p>
3683 <p>
3684 Moved to NAD.
3685 </p>
3686 </blockquote>
3687
3688
3689
3690 <p><b>Proposed resolution:</b></p>
3691 <blockquote>
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
3694 follows:</p>
3695 <pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
3696       InputIterator find(InputIterator first, InputIterator last,
3697                          const T&amp; value, BinaryPredicate bin_pred);</pre>
3698 <p>Change the description of the return from:</p>
3699 <blockquote>
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>
3702 </blockquote>
3703 <p>&nbsp;to:</p>
3704 <blockquote>
3705   <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
3706   corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
3707   != false. Return last if no such iterator is found.</p>
3708 </blockquote>
3709 </blockquote>
3710
3711
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.&nbsp; As the submitter pointed out, "this can
3715 be accomplished using a combination of find_if and bind_1st or
3716 bind_2nd".</p>
3717
3718
3719
3720
3721 <hr>
3722 <h3><a name="236"></a>236. ctype&lt;char&gt;::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>
3734
3735
3736 <p><b>Proposed resolution:</b></p>
3737   <p>Change paragraph 4 from</p>
3738     <blockquote><p>
3739     The second form, for all *p in the range [low, high), assigns
3740     vec[p-low] to table()[(unsigned char)*p].
3741     </p></blockquote>
3742   <p>to become</p>
3743     <blockquote><p>
3744     The second form, for all *p in the range [low, high), assigns
3745     table()[(unsigned char)*p] to vec[p-low].
3746   </p></blockquote>
3747
3748
3749 <p><b>Rationale:</b></p>
3750
3751
3752
3753
3754
3755 <hr>
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>
3763
3764 <pre>        template&lt;class Iter, class X&gt;
3765         Iter find(Iter begin, Iter end, const X&amp; x)
3766         {
3767             X x1 = x;           // this is the crucial statement
3768             while (begin != end &amp;&amp; *begin != x1)
3769                 ++begin;
3770             return begin;
3771         }
3772 </pre>
3773
3774 <p>If the answer is yes, then it is implementation-dependent as to
3775 whether the following fragment is well formed:</p>
3776
3777 <pre>        vector&lt;string&gt; v;
3778
3779         find(v.begin(), v.end(), "foo");
3780 </pre>
3781
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>
3785
3786
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>
3792
3793
3794
3795
3796 <hr>
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>
3805
3806 <pre>        istream_iterator&lt;int&gt; i(cin);
3807
3808         int n = *i++;
3809 </pre>
3810
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?
3813 More?</p>
3814
3815
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>
3821
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>
3825
3826
3827
3828
3829 <hr>
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>
3843
3844 <ol>
3845    <li><p> The specification is inconsistent with the original
3846    proposal and with several implementations.</p>
3847
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
3858    practice.</p></li>
3859
3860    <li><p>
3861    The specification is inconsistent with insertion for sequence
3862    containers.</p>
3863
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>
3868
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>
3872
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>
3878
3879    <li><p> When appending sorted ranges using insert_iterators,
3880    insertions are guaranteed to be sub-optimal.</p>
3881
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
3888    time.</p></li>
3889 </ol>
3890
3891
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>
3895
3896 <p><i>assertion/note pre/post condition:</i>
3897 <br>Change the last sentence from</p>
3898      <blockquote><p>
3899      "iterator p is a hint pointing to where the insert should
3900      start to search."
3901      </p></blockquote>
3902 <p>to</p>
3903      <blockquote><p>
3904      "iterator p is a hint indicating that immediately before p
3905      may be a correct location where the insertion could occur."
3906      </p></blockquote>
3907
3908 <p><i>complexity:</i><br>
3909 Change the words "right after" to "immediately before".</p>
3910
3911
3912 <p><b>Rationale:</b></p>
3913
3914
3915
3916
3917
3918 <hr>
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>
3929
3930 <pre>    int x,y,z;
3931     x = y = z = 1;
3932 </pre>
3933
3934 <p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3935 <pre>    auto_ptr&lt;int&gt; x, y, z;
3936     z.reset(new int(1));
3937     x = y = z;
3938 </pre>
3939
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>
3944
3945
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>
3949
3950
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
3955 code.</p>
3956
3957
3958
3959
3960 <hr>
3961 <h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::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>
3967 <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&lt;int&gt;::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.
3980 </p>
3981
3982 <p><i>[
3983 2009-07 Frankfurt
3984 ]</i></p>
3985
3986
3987 <blockquote>
3988 <p>
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.
3991 </p>
3992 <p>
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.
3995 </p>
3996 <p>
3997 int is big enough for reasonable buffers.
3998 </p>
3999 <p>
4000 Move to NAD Future.
4001 </p>
4002 <p>
4003 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>.
4004 </p>
4005 </blockquote>
4006
4007
4008
4009 <p><b>Proposed resolution:</b></p>
4010 <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.
4014 </p>
4015
4016 <p>
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.
4024 </p>
4025
4026 <p>
4027 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
4028 </p>
4029
4030 <p>
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):
4035 </p>
4036
4037 <blockquote><p>
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]
4043 </p></blockquote>
4044
4045 <p>
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.
4049 </p>
4050
4051
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
4056 signature.</p>
4057 <p><i>[
4058 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
4059 ]</i></p>
4060
4061
4062
4063
4064
4065 <hr>
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>
4072 <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.
4077 </p>
4078
4079 <p>Defect:
4080 <br>
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
4083 destructors.
4084 </p>
4085
4086 <p>Attribution:
4087 <br>
4088 Wil Evers and William E. Kempf suggested this modification for functional
4089 objects.
4090 </p>
4091
4092
4093 <p><b>Proposed resolution:</b></p>
4094 <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).
4100 </p>
4101
4102 <p>
4103 As an example, replace...
4104 </p>
4105
4106 <pre>    template &lt;class Arg, class Result&gt;
4107     struct unary_function {
4108             typedef Arg    argument_type;
4109             typedef Result result_type;
4110     };
4111 </pre>
4112
4113 <p>
4114 ... with...
4115 </p>
4116
4117 <pre>    template &lt;class Arg, class Result&gt;
4118     struct unary_function {
4119             typedef Arg    argument_type;
4120             typedef Result result_type;
4121     protected:
4122             ~unary_function() {}
4123     };
4124 </pre>
4125
4126 <p>
4127 Affected definitions:
4128 <br>
4129   &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
4130   <br>
4131   &nbsp;24.3.2 [lib.iterator.basic] -- iterator
4132 </p>
4133
4134
4135 <p><b>Rationale:</b></p>
4136 <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.
4143 </p>
4144
4145
4146
4147
4148
4149 <hr>
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>
4156 <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:
4161 </p>
4162
4163 <pre>    #include &lt;strstream&gt;
4164
4165     int main ()
4166     {
4167          std::strstreambuf sb;
4168          sb.sputc ('c');
4169
4170          sb.pubseekoff (-1, std::ios::end, std::ios::in);
4171          return !('c' == sb.sgetc ());
4172     }
4173 </pre>
4174
4175 <p>
4176 D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
4177 which in turn sets all pointers to 0 in 27.5.2.1, p1.
4178 </p>
4179  
4180 <p>
4181 27.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::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).
4184 </p>
4185
4186 <p>
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).
4190 </p>
4191
4192 <p>
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().
4196 </p>
4197
4198 <p>
4199 D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
4200 gptr() == epptr() + off holds.
4201 </p>
4202
4203 <p>
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.
4209 </p>
4210
4211
4212 <p><b>Proposed resolution:</b></p>
4213
4214
4215    <p>Change the last sentence of D.9.1 [depr.strstreambuf] paragraph 4 from</p>
4216
4217       <blockquote><p>
4218       Otherwise, seeklow equals gbeg and seekhigh is either pend, if
4219       pend is not a null pointer, or gend.
4220       </p></blockquote>
4221
4222    <p>to become</p>
4223
4224       <blockquote><p>
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.
4228       </p></blockquote>
4229
4230 <p><i>[
4231   pre-Copenhagen: Dietmar provided wording for proposed resolution.
4232 ]</i></p>
4233
4234
4235 <p><i>[
4236   post-Copenhagen: Fixed a typo: proposed resolution said to fix
4237   4.7.1, not D.7.1.
4238 ]</i></p>
4239
4240
4241
4242
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>
4248
4249
4250
4251
4252
4253 <hr>
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>
4260 <p>
4261 One of our customers asks whether this is valid C++:
4262 </p>
4263
4264 <pre>   #include &lt;cstdarg&gt;
4265
4266    void bar(const char *, va_list);
4267
4268    void
4269    foo(const char *file, const char *, ...)
4270    {
4271      va_list ap;
4272      va_start(ap, file);
4273      bar(file, ap);
4274      va_end(ap);
4275    }
4276 </pre>
4277
4278 <p>
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?
4285 </p>
4286
4287 <p>
4288 My personal opinion is that this should be allowed, but some tweak
4289 might be required in the C++ standard.
4290 </p>
4291
4292
4293 <p><b>Rationale:</b></p>
4294 <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.
4300 </p>
4301
4302 <p>
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
4308 necessary.
4309 </p>
4310
4311
4312
4313
4314 <hr>
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>
4321 <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.
4328 </p>
4329
4330
4331 <p><b>Proposed resolution:</b></p>
4332 <p>
4333 In 20.1.5, paragraph 5, change "Implementors" to
4334 "Implementors of the library described in this International
4335 Standard".
4336 </p>
4337
4338
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>
4343
4344
4345
4346
4347
4348 <hr>
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>
4355
4356 <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.
4360 </p>
4361
4362 <p>
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."
4365 </p>
4366
4367 <p>
4368 (Comment from Judy)
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.
4373 </p>
4374
4375
4376 <p><b>Proposed resolution:</b></p>
4377 <p>
4378 In <b>Section:</b> 23.2 [container.requirements],
4379 table 65, in the assertion/note pre/post condition for X::const_iterator,
4380 add the following:
4381 </p>
4382
4383 <blockquote>
4384 <p>
4385 typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
4386 </p>
4387
4388 <p>
4389 typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
4390 </p>
4391
4392 <p>
4393 typeid(X::const_iterator::category) == typeid(X::iterator::category)
4394 </p>
4395 </blockquote>
4396
4397
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>
4407
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>
4410
4411
4412
4413
4414
4415
4416 <hr>
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>
4423 <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.
4429 </p>
4430
4431 <p>
4432 I see three possible solutions: 
4433 </p>
4434
4435 <ol>
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
4440 set failbit. </li>
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>
4446 </ol>
4447
4448 <p>
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. 
4452 </p>
4453
4454 <p>
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 
4458 ios_base::dec.
4459 </p>
4460
4461
4462 <p><b>Proposed resolution:</b></p>
4463
4464
4465 <p><b>Rationale:</b></p>
4466 <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
4474 section.
4475 </p>
4476 <p>
4477 Users are advised to use manipulators, or else use the two-argument
4478 version of <tt>setf</tt>, to avoid unexpected behavior.
4479 </p>
4480
4481
4482
4483
4484
4485 <hr>
4486 <h3><a name="289"></a>289. &lt;cmath&gt; 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>
4492 <p>
4493     In ISO/IEC 9899:1990 Programming Languages C we find the following
4494     concerning &lt;math.h&gt;:
4495 </p>
4496
4497 <blockquote><p>
4498          7.13.4 Mathematics &lt;math.h&gt;
4499          <br>
4500          The names of all existing functions declared in the &lt;math.h&gt;
4501          header, suffixed with f or l, are reserved respectively for
4502          corresponding functions with float and long double arguments
4503          are return values.
4504 </p></blockquote>
4505
4506 <p>
4507     For example, <tt>float&nbsp;sinf(float)</tt>
4508     is reserved.
4509 </p>
4510
4511 <p>
4512     In the C99 standard, &lt;math.h&gt; must contain declarations
4513     for these functions.
4514 </p>
4515
4516 <p>
4517 So, is it acceptable for an implementor to add these prototypes to the
4518 C++ versions of the math headers? Are they required?
4519 </p>
4520
4521
4522 <p><b>Proposed resolution:</b></p>
4523 <p>
4524 Add these Functions to Table 80, section 26.5 and to Table 99,
4525 section C.2:
4526 </p>
4527
4528 <pre>    acosf asinf atanf atan2f ceilf cosf coshf 
4529     expf fabsf floorf fmodf frexpf ldexpf 
4530     logf log10f modff powf sinf sinhf sqrtf 
4531     tanf tanhf 
4532     acosl asinl atanl atan2l ceill cosl coshl 
4533     expl fabsl floorl fmodl frexpl ldexpl 
4534     logl log10l modfl powl sinl sinhl sqrtl 
4535     tanl tanhl
4536 </pre>
4537
4538 <p>
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. 
4543 </p>
4544
4545
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>
4551
4552
4553
4554
4555
4556 <hr>
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.
4570 </p>
4571
4572 <p>I don't see how any implementation can give such a guarantee
4573 without imposing requirements on the function object.
4574 </p>
4575
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?
4579 </p>
4580
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.
4586 </p>
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>
4592
4593
4594 <p><i>[
4595 2009-07 Frankfurt
4596 ]</i></p>
4597
4598
4599 <blockquote>
4600 <p>
4601 Moved to NAD.
4602 </p>
4603 <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
4606 of the library.
4607 </p>
4608 </blockquote>
4609
4610
4611
4612 <p><b>Proposed resolution:</b></p>
4613
4614
4615
4616
4617
4618
4619 <hr>
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.
4635 </p>
4636
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
4645 elements.
4646 </p>
4647
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
4654 objects.
4655 </p>
4656
4657
4658 <p><b>Proposed resolution:</b></p>
4659 <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
4660 <blockquote><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))).
4665 </p></blockquote>
4666 <p>to:</p>
4667 <blockquote><p>
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
4671 corresponding
4672 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
4673 (i - result), *(first2 + (i - result))).
4674 </p></blockquote>
4675
4676
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>
4683
4684
4685
4686
4687
4688 <hr>
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>
4695 <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&amp;.  *r++ = t is valid while *r-- = t is invalid.
4700 </p>
4701
4702 <p>
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&amp; by
4706 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
4707 </p>
4708
4709 <p>
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
4722 code.
4723 </p>
4724
4725 <p>
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.
4737 </p>
4738
4739 <p>
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.
4745 </p>
4746
4747 <p>Further discussion: I propose a compromise between John Potter's
4748 resolution, which requires <tt>T&amp;</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).
4758 </p>
4759
4760 <p>
4761 Note that the compromise resolution necessitates a change to
4762 <tt>reverse_iterator</tt>. It would need to use a proxy to support
4763 <tt>a[n] = t</tt>.
4764 </p>
4765
4766 <p>
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>.
4774 </p>
4775
4776 <p><i>[
4777 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
4778 ]</i></p>
4779
4780
4781 <p><i>[
4782 2009-09-18 Alisdair adds:
4783 ]</i></p>
4784
4785
4786 <blockquote>
4787 <p>
4788 Why can't we write through the reference returned from operator[] on a
4789 random access iterator?
4790 </p>
4791
4792 <p>
4793 Recommended solution:
4794 </p>
4795
4796 <p>
4797 In table Table 104 -- Random access iterator requirements, replace
4798 </p>
4799
4800 <blockquote>
4801 a[n] : convertible to <del><tt>const T &amp;</tt></del>
4802 <ins><tt>T&amp;</tt> if <tt>X</tt> is mutable, otherwise convertible to <tt>const T&amp;</tt></ins>
4803 </blockquote>
4804 </blockquote>
4805
4806 <p><i>[
4807 2009-10 Santa Cruz:
4808 ]</i></p>
4809
4810
4811 <blockquote>
4812 Leave Open. Alisdair to spearhead a paper on revivification.
4813 </blockquote>
4814
4815 <p><i>[
4816 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
4817 ]</i></p>
4818
4819
4820
4821
4822 <p><b>Rationale:</b></p>
4823 <p>
4824 Solved by
4825 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
4826 </p>
4827
4828
4829 <p><b>Proposed resolution:</b></p>
4830
4831 <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
4834 <tt>T&amp;</tt>.
4835 </p>
4836
4837 <p>
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>.
4844 </p>
4845
4846 <p><i>[Lillehammer: Real problem, but should be addressed as part of
4847   iterator redesign]</i></p>
4848
4849
4850
4851
4852 <p><b>Rationale:</b></p>
4853 <p><i>[
4854 San Francisco:
4855 ]</i></p>
4856
4857
4858 <blockquote>
4859 Solved by
4860 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
4861 </blockquote>
4862
4863
4864
4865
4866
4867
4868
4869 <hr>
4870 <h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::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>
4876 <p>
4877 The effects of <tt>codecvt&lt;&gt;::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&lt;&gt;::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&lt;&gt;::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.
4885 </p>
4886
4887 <p>
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).
4892 </p>
4893
4894
4895 <p><b>Proposed resolution:</b></p>
4896 <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
4900 state.
4901 </p>
4902
4903 <p>
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:
4908 </p>
4909
4910 <pre>  int length(stateT&amp; state, 
4911              const externT* from, 
4912              const externT* from_end, 
4913              size_t max,
4914              const externT** from_next = 0);
4915
4916   virtual
4917   int do_length(stateT&amp; state, 
4918                 const externT* from, 
4919                 const externT* from_end, 
4920                 size_t max,
4921                 const externT** from_next);
4922 </pre>
4923
4924 <p>
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.
4928 </p>
4929
4930
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>
4935
4936
4937
4938
4939
4940 <hr>
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>
4947 <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.
4950 </p>
4951
4952 <p>
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).
4955 </p>
4956
4957 <p>The problem occurs in the following entry:</p>
4958
4959 <pre>  a-&gt;m     pre: (*a).m is well-defined
4960            Equivalent to (*a).m
4961 </pre>
4962
4963 <p>
4964 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
4965 type, but since <tt>operator-&gt;()</tt> must return a pointer for
4966 <tt>a-&gt;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.
4969 </p>
4970
4971 <p>I don't think this was intentional.</p>
4972
4973
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-&gt;
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>
4980
4981
4982
4983
4984
4985 <hr>
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>
4992 <p>
4993 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
4994 (27.7.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::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
4999 others propagate.
5000 </p>
5001
5002 <p>
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&lt;&gt;::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
5011 contradictory.
5012 </p>
5013
5014 <p>
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&lt;&gt;::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()-&gt;flush(), the only called function,
5020 throws an exception (typically, it's badbit that's set in response to
5021 such an event).
5022 </p>
5023
5024 <p><b>Additional comments from Martin, who isn't comfortable with the
5025     current proposed resolution</b> (see c++std-lib-11530)</p>
5026
5027 <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].
5042 </p>
5043
5044 <p>
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.
5051 </p>
5052
5053 <p>
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().
5062 </p>
5063
5064 <p>
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].)
5071 </p>
5072
5073 <p>
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)
5080 </p>
5081
5082 <p>
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].
5091 </p>
5092
5093 <p>
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().
5101 </p>
5102
5103
5104 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
5105
5106 <blockquote>
5107 <pre>struct S { long i; };
5108
5109 istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
5110 {
5111     ios::iostate err = ios::goodbit;
5112     try {
5113         const istream::sentry guard (strm, false);
5114         if (guard) {
5115             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
5116                 .get (istreambuf_iterator&lt;char&gt;(strm),
5117                       istreambuf_iterator&lt;char&gt;(),
5118                       strm, err, s.i);
5119         }
5120     }
5121     catch (...) {
5122         bool rethrow;
5123         try {
5124             strm.setstate (ios::badbit);
5125             rethrow = false;
5126         }
5127         catch (...) {
5128             rethrow = true;
5129         }
5130         if (rethrow)
5131             throw;
5132     }
5133     if (err)
5134         strm.setstate (err);
5135     return strm;
5136 }
5137 </pre>
5138 </blockquote>
5139
5140 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
5141
5142 <blockquote>
5143 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
5144 {
5145     istream::sentry guard (strm, false);
5146     if (guard) {
5147         ios::iostate err = ios::goodbit;
5148         try {
5149             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
5150                 .get (istreambuf_iterator&lt;char&gt;(strm),
5151                       istreambuf_iterator&lt;char&gt;(),
5152                       strm, err, s.i);
5153         }
5154         catch (...) {
5155             bool rethrow;
5156             try {
5157                 strm.setstate (ios::badbit);
5158                 rethrow = false;
5159             }
5160             catch (...) {
5161                 rethrow = true;
5162             }
5163             if (rethrow)
5164                 throw;
5165         }
5166         if (err)
5167             strm.setstate (err);
5168     }
5169     return strm;
5170 }
5171 </pre>
5172 </blockquote>
5173
5174 <p>
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().
5178 </p>
5179
5180 <blockquote>
5181 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
5182 {
5183     const ios::iostate state = strm.rdstate ();
5184     const ios::iostate except = strm.exceptions ();
5185     ios::iostate err = std::ios::goodbit;
5186     bool thrown = true;
5187     try {
5188         const istream::sentry guard (strm, false);
5189         thrown = false;
5190         if (guard) {
5191             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
5192                 .get (istreambuf_iterator&lt;char&gt;(strm),
5193                       istreambuf_iterator&lt;char&gt;(),
5194                       strm, err, s.i);
5195         }
5196     }
5197     catch (...) {
5198         if (thrown &amp;&amp; state &amp; except)
5199             throw;
5200         try {
5201             strm.setstate (ios::badbit);
5202             thrown = false;
5203         }
5204         catch (...) {
5205             thrown = true;
5206         }
5207         if (thrown)
5208             throw;
5209     }
5210     if (err)
5211         strm.setstate (err);
5212
5213     return strm;
5214 }
5215 </pre>
5216 </blockquote>
5217
5218 <p>
5219 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
5220 </p>
5221
5222 <p>
5223 [Pre-Portland] A relevant newsgroup post:
5224 </p>
5225
5226 <p>
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
5232 experience.
5233 </p>
5234 <p>
5235 In the course of writing software for commercial use, I constructed
5236 std::ifstream's based on user-supplied pathnames on typical POSIX
5237 systems.
5238 </p>
5239 <p>
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
5245 custom streambufs).
5246 </p>
5247 <p>
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.
5251 </p>
5252 <p>
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&gt;&gt;( T&amp; ) 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&gt;&gt;())
5258 was not catching exceptions in this situation.
5259 </p>
5260 <p>
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.
5264 </p>
5265 <p>
5266 Also, calling .peek() on the istream before calling the extractor()
5267 changed the behavior (.peek() had the effect of setting the badbit
5268 ahead of time).
5269 </p>
5270 <p>
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
5274 committee.
5275 </p>
5276
5277 <p><i>[
5278 2009-07 Frankfurt
5279 ]</i></p>
5280
5281
5282 <blockquote>
5283 <p>
5284 Moved to NAD.
5285 </p>
5286 <p>
5287 See the rationale in the issue. Paolo, who requested that the issue be
5288 reopened, agreed with the rationale.
5289 </p>
5290 </blockquote>
5291
5292
5293
5294 <p><b>Proposed resolution:</b></p>
5295
5296
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>
5303
5304
5305
5306
5307
5308 <hr>
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>
5315 <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.
5319 </p>
5320
5321 <p>
5322 Question: what if the terminate_handler in effect is itself
5323 std::terminate?
5324 </p>
5325
5326 <p>For example:</p>
5327
5328 <pre>  #include &lt;exception&gt;
5329
5330   int main () {
5331       std::set_terminate(std::terminate);
5332       throw 5;
5333       return 0;
5334   }
5335 </pre>
5336
5337 <p>
5338 Is the implementation allowed to go into an infinite loop?
5339 </p>
5340
5341 <p>
5342 I think the same issue applies to std::set_unexpected.
5343 </p>
5344
5345
5346 <p><b>Proposed resolution:</b></p>
5347
5348
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>
5352 to call itself.</p>
5353
5354
5355
5356
5357
5358 <hr>
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>
5365
5366 <p>
5367 The standard appears to contradict itself about whether the stack is
5368 unwound when the implementation calls terminate().
5369 </p>
5370
5371 <p>From 18.7.3.3p2:</p>
5372 <blockquote><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 [...]
5376 </p></blockquote>
5377
5378 <p>So the stack is guaranteed not to be unwound.</p>
5379
5380 <p>But from 15.3p9:</p>
5381 <blockquote><p>
5382     [...]whether or not the stack is unwound before this call
5383     to terminate() is implementation-defined (except.terminate).
5384 </p></blockquote>
5385
5386 <p>
5387 And 15.5.1 actually defines that in most cases the stack is unwound.
5388 </p>
5389
5390
5391 <p><b>Proposed resolution:</b></p>
5392
5393
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>
5400
5401
5402
5403
5404
5405 <hr>
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
5413 abs():</p>
5414
5415 <pre>    abs(long), abs(int) in &lt;cstdlib&gt;
5416
5417     abs(float), abs(double), abs(long double) in &lt;cmath&gt;
5418
5419     template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
5420
5421     template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
5422 </pre>
5423
5424 <p>
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
5430 selected.
5431 </p>
5432
5433 <p>
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.
5439 </p>
5440
5441 <p>The same issue may exist for other functions in the library.</p>
5442
5443 <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
5444 and int_max_abs.</p>
5445
5446 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>.</p>
5447
5448 <p><i>[
5449 Bellevue:
5450 ]</i></p>
5451
5452
5453 <blockquote>
5454 The situation is not sufficiently severe to warrant a change.
5455 </blockquote>
5456
5457
5458
5459
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 &lt;cstdlib&gt;, the <tt>float</tt> version if the user
5467   included &lt;cmath&gt;, 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>
5472
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>&lt;all&gt;</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>
5479
5480
5481
5482
5483
5484 <hr>
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>
5493
5494
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>
5499
5500
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>
5504
5505
5506
5507
5508
5509 <hr>
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>
5516 <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.
5527 </p>
5528
5529 <p>
5530 For instance, the following code will (presumably) incorrectly copy facets
5531 belonging to the collate category from the German locale on AIX:
5532 </p>
5533
5534 <pre>  std::locale l (std::locale ("C"), "de_DE", std::locale::none);
5535 </pre>
5536
5537
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 &lt;cctype&gt;.  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>
5552
5553 <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
5554
5555
5556
5557
5558
5559 <hr>
5560 <h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </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>
5566 <p>
5567 Increment and decrement operators are missing from 
5568 Table 88 -- Position type requirements in 27.5.3 [fpos].
5569 </p>
5570
5571
5572 <p><b>Proposed resolution:</b></p>
5573 <p>
5574 Table 88 (section 27.4.3) -- Position type requirements
5575 be updated to include increment and decrement operators.
5576 </p>
5577
5578 <pre>expression        return type     operational    note
5579
5580 ++p               fpos&amp;           p += O(1)
5581 p++               fpos            { P tmp = p;
5582                                     ++p;
5583                                     return tmp; }
5584 --p               fpos&amp;           p -= O(1)
5585 p--               fpos            { P tmp = p;
5586                                     --p;
5587                                     return tmp; }
5588 </pre>
5589
5590
5591
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>
5596
5597
5598
5599
5600
5601 <hr>
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>
5609
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
5612 like:</p>
5613
5614 <blockquote><p>
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()-&gt;pubseekpos( pos).
5620 </p></blockquote>
5621
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>
5624
5625 <blockquote><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()&amp;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.
5643 </p></blockquote>
5644
5645 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
5646
5647 <blockquote><p>
5648 If, after any preparation is completed, is.good() is true, ok_ != false 
5649 otherwise, ok_ == false.
5650 </p></blockquote>
5651
5652 <p>
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.
5658 </p>
5659
5660 <p><b>Further discussion from Redmond:</b></p>
5661
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
5668 ought to be OK.</p>
5669
5670 <p>
5671 Pre-Berlin:  Paolo points out several problems with the proposed resolution in
5672 Ready state:
5673 </p>
5674
5675 <ul>
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>
5680 if the sentry
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>
5683 </ul>
5684
5685 <p><i>[
5686 2009-07 Frankfurt
5687 ]</i></p>
5688
5689
5690 <blockquote>
5691 <p>
5692 Moved to NAD. Will reopen if proposed resolution is supplied.
5693 </p>
5694 </blockquote>
5695
5696
5697
5698 <p><b>Proposed resolution:</b></p>
5699
5700 <p>Change 27.7.1.3 [istream.unformatted] to:</p>
5701 <blockquote><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()-&gt;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>).
5711 </p></blockquote>
5712
5713 <p><i>[Lillehammer: Matt provided wording.]</i></p>
5714
5715
5716
5717
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>
5725
5726
5727
5728
5729
5730 <hr>
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>
5738 <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.
5745 </p>
5746
5747 <p>
5748 For instance, although it is not explicitly specified in the synopsis of
5749 &lt;string&gt;, 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 &lt;memory&gt; from within &lt;string&gt;,
5752 either directly or indirectly, to bring the declaration of
5753 std::allocator into scope.
5754 </p>
5755
5756 <p>
5757 Additionally, however, some implementation also include &lt;istream&gt; and
5758 &lt;ostream&gt; at the top of &lt;string&gt; 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 &lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
5763 full definitions are necessary.
5764 </p>
5765
5766 <p>
5767 Obviously, it is possible to implement &lt;string&gt; 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.
5772 </p>
5773
5774 <p>
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 &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
5778 reasonable to also expect it to explicitly include &lt;memory&gt;. 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.
5782 </p>
5783
5784 <p>The examples below demonstrate the issue.</p>
5785
5786 <p>Example 1:</p>
5787
5788 <p>It is not clear whether the following program is complete:</p>
5789
5790 <pre>#include &lt;string&gt;
5791
5792 extern std::basic_ostream&lt;char&gt; &amp;strm;
5793
5794 int main () {
5795     strm &lt;&lt; std::string ("Hello, World!\n");
5796 }
5797 </pre>    
5798
5799 <p>or whether one must explicitly include &lt;memory&gt; or
5800 &lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
5801 the program to compile.</p>
5802
5803
5804 <p>Example 2:</p>
5805
5806 <p>Similarly, it is unclear whether the following program is complete:</p>
5807
5808 <pre>#include &lt;istream&gt;
5809
5810 extern std::basic_iostream&lt;char&gt; &amp;strm;
5811
5812 int main () {
5813     strm &lt;&lt; "Hello, World!\n";
5814 }
5815 </pre>
5816
5817 <p>
5818 or whether one needs to explicitly include &lt;ostream&gt;, and
5819 perhaps even other headers containing the definitions of other
5820 required templates:</p>
5821
5822 <pre>#include &lt;ios&gt;
5823 #include &lt;istream&gt;
5824 #include &lt;ostream&gt;
5825 #include &lt;streambuf&gt;
5826
5827 extern std::basic_iostream&lt;char&gt; &amp;strm;
5828
5829 int main () {
5830     strm &lt;&lt; "Hello, World!\n";
5831 }
5832 </pre>
5833
5834 <p>Example 3:</p>
5835
5836 <p>Likewise, it seems unclear whether the program below is complete:</p>
5837 <pre>#include &lt;iterator&gt;
5838
5839 bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
5840 {
5841     return a == b;
5842 }
5843
5844 int main () { }
5845 </pre>
5846
5847 <p>or whether one should be required to include &lt;istream&gt;.</p>
5848
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>
5856
5857 <p><i>[
5858 post Bellevue:
5859 ]</i></p>
5860
5861
5862 <blockquote>
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
5866 author.
5867 </blockquote>
5868
5869 <p><i>[
5870 2009-07 Frankfurt
5871 ]</i></p>
5872
5873
5874 <blockquote>
5875 NAD. Handled by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.
5876 </blockquote>
5877
5878
5879
5880 <p><b>Proposed resolution:</b></p>
5881 <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):
5886 </p>
5887
5888 <pre>+------------+--------------------+
5889 | C++ header |required to include |
5890 +============+====================+
5891 |&lt;algorithm&gt; |                    |
5892 +------------+--------------------+
5893 |&lt;bitset&gt;    |                    |
5894 +------------+--------------------+
5895 |&lt;complex&gt;   |                    |
5896 +------------+--------------------+
5897 |&lt;deque&gt;     |&lt;memory&gt;            |
5898 +------------+--------------------+
5899 |&lt;exception&gt; |                    |
5900 +------------+--------------------+
5901 |&lt;fstream&gt;   |&lt;ios&gt;               |
5902 +------------+--------------------+
5903 |&lt;functional&gt;|                    |
5904 +------------+--------------------+
5905 |&lt;iomanip&gt;   |&lt;ios&gt;               |
5906 +------------+--------------------+
5907 |&lt;ios&gt;       |&lt;streambuf&gt;         |
5908 +------------+--------------------+
5909 |&lt;iosfwd&gt;    |                    |
5910 +------------+--------------------+
5911 |&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
5912 +------------+--------------------+
5913 |&lt;istream&gt;   |&lt;ios&gt;               |
5914 +------------+--------------------+
5915 |&lt;iterator&gt;  |                    |
5916 +------------+--------------------+
5917 |&lt;limits&gt;    |                    |
5918 +------------+--------------------+
5919 |&lt;list&gt;      |&lt;memory&gt;            |
5920 +------------+--------------------+
5921 |&lt;locale&gt;    |                    |
5922 +------------+--------------------+
5923 |&lt;map&gt;       |&lt;memory&gt;            |
5924 +------------+--------------------+
5925 |&lt;memory&gt;    |                    |
5926 +------------+--------------------+
5927 |&lt;new&gt;       |&lt;exception&gt;         |
5928 +------------+--------------------+
5929 |&lt;numeric&gt;   |                    |
5930 +------------+--------------------+
5931 |&lt;ostream&gt;   |&lt;ios&gt;               |
5932 +------------+--------------------+
5933 |&lt;queue&gt;     |&lt;deque&gt;             |
5934 +------------+--------------------+
5935 |&lt;set&gt;       |&lt;memory&gt;            |
5936 +------------+--------------------+
5937 |&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
5938 +------------+--------------------+
5939 |&lt;stack&gt;     |&lt;deque&gt;             |
5940 +------------+--------------------+
5941 |&lt;stdexcept&gt; |                    |
5942 +------------+--------------------+
5943 |&lt;streambuf&gt; |&lt;ios&gt;               |
5944 +------------+--------------------+
5945 |&lt;string&gt;    |&lt;memory&gt;            |
5946 +------------+--------------------+
5947 |&lt;strstream&gt; |                    |
5948 +------------+--------------------+
5949 |&lt;typeinfo&gt;  |&lt;exception&gt;         |
5950 +------------+--------------------+
5951 |&lt;utility&gt;   |                    |
5952 +------------+--------------------+
5953 |&lt;valarray&gt;  |                    |
5954 +------------+--------------------+
5955 |&lt;vector&gt;    |&lt;memory&gt;            |
5956 +------------+--------------------+
5957 </pre>
5958
5959
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 &lt;all&gt; header.</p>
5967
5968 <p>
5969 Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
5970 </p>
5971
5972
5973
5974
5975
5976
5977
5978 <hr>
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>
5984 <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?
5988 </p>
5989 <p>
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.
5994 </p>
5995
5996 <p><b>Proposed resolution:</b></p>
5997 <p>
5998 Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
5999 sentence:
6000 </p>
6001 <blockquote><p>
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).
6008 </p></blockquote>
6009
6010 <p><b>Rationale:</b></p>
6011 <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.
6017 </p>
6018
6019
6020
6021
6022 <hr>
6023 <h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</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>
6030
6031
6032 <p>
6033 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
6034 operator&lt; on any pair type which contains a pointer.
6035 </p>
6036
6037
6038 <p><b>Proposed resolution:</b></p>
6039 <p>In 20.3.5 [pairs] paragraph 6, replace:</p>
6040 <pre>    Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
6041         y.second).
6042 </pre>
6043 <p>With:</p>
6044 <pre>    Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
6045              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp; 
6046              std::less&lt;T2&gt;()( x.second, y.second ) )
6047 </pre>
6048
6049
6050
6051 <p><b>Rationale:</b></p>
6052 <p>This is an instance of a much more general problem.  If we want
6053   operator&lt; 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&lt;T*&gt;, and so
6056   on.</p>
6057
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>
6064
6065
6066
6067
6068
6069
6070 <hr>
6071 <h3><a name="350"></a>350. allocator&lt;&gt;::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>
6080
6081 <p>
6082 The core language feature allowing definition of operator&amp;() 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
6086 the fragment</p>
6087 <pre>  class A { private: A* operator&amp;(); };
6088   std::vector&lt;A&gt; aa;
6089
6090   class B { };
6091   B* operator&amp;(B&amp;) { return 0; }
6092   std::vector&lt;B&gt; ba;
6093 </pre>
6094
6095 <p>
6096 In particular, the requirements table for Allocator (Table 32) specifies
6097 no semantics at all for member address(), and allocator&lt;&gt;::address is 
6098 defined in terms of unadorned operator &amp;.
6099 </p>
6100
6101
6102
6103 <p><b>Proposed resolution:</b></p>
6104 <p>
6105 In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
6106 <blockquote><p>
6107   Returns: &amp;x
6108 </p></blockquote>
6109
6110 <p>to:</p>
6111
6112 <p>
6113   Returns: The value that the built in operator&amp;(x) would return if not 
6114   overloaded.
6115 </p>
6116
6117 <p>
6118 In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
6119 a.address(s) lines, respectively: 
6120 </p>
6121
6122 <pre>  allocator&lt;T&gt;::address(r)
6123   allocator&lt;T&gt;::address(s)
6124 </pre> 
6125
6126 <p>In addition, in clause 17.4.1.1, add a statement:</p>
6127
6128 <blockquote><p>
6129  The Standard Library does not apply operator&amp; to any type for which
6130  operator&amp; may be overloaded.
6131 </p></blockquote> 
6132
6133
6134
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 &amp;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>
6144
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
6149   larger issue.</p>
6150
6151
6152
6153
6154
6155 <hr>
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>
6162 <p>
6163 In 20.8 [function.objects] the header &lt;functional&gt; 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.
6169 </p>
6170
6171 <p><i>[Taken from comp.std.c++]</i></p>
6172
6173
6174
6175 <p><b>Proposed resolution:</b></p>
6176 <p>Change the synopsis to reflect the useage in 20.8.9 [negators]</p>
6177
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>
6181
6182
6183
6184
6185
6186
6187
6188 <hr>
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>
6195
6196 <p>What should the following program print?</p>
6197
6198 <pre>  #include &lt;locale&gt;
6199   #include &lt;iostream&gt;
6200
6201   class my_ctype : public std::ctype&lt;char&gt;
6202   {
6203     typedef std::ctype&lt;char&gt; base;
6204   public:
6205     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
6206     {
6207       std::copy(base::classic_table(), base::classic_table() + base::table_size,
6208                 my_table);
6209       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
6210     }
6211   private:
6212     mask my_table[base::table_size];
6213   };
6214
6215   int main()
6216   {
6217     my_ctype ct;
6218     std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
6219               &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
6220   }
6221 </pre>
6222
6223 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
6224
6225 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
6226 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
6227
6228 <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>
6232
6233 <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.
6244 </p>
6245
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&lt;char&gt;, 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.
6255 </p>
6256
6257 <p>
6258 Related reflector messages:
6259 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
6260 lib-9277, lib-9279.
6261 </p>
6262
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>
6268
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>
6272
6273 <blockquote>
6274 <pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
6275 --------
6276
6277 #include &lt;locale&gt;
6278 #include &lt;iostream&gt;
6279
6280 class my_ctype : public std::ctype&lt;char&gt;
6281 {
6282 private:
6283   typedef std::ctype&lt;char&gt; base;
6284   mask my_table[base::table_size];
6285
6286 public:
6287   my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
6288   {
6289     std::copy(base::classic_table(), base::classic_table() + base::table_size,
6290               my_table);
6291     mask both = base::print | base::space;
6292     my_table[static_cast&lt;mask&gt;('_')] = both;
6293   }
6294 };
6295
6296 int main()
6297 {
6298   using namespace std;
6299   my_ctype ct;
6300   cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
6301   cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
6302
6303   // ISO C99, isalpha iff upper | lower set, and !space.
6304   // 7.5, p 193
6305   // -&gt; looks like g++ behavior is correct.
6306   // 356 -&gt; bitmask elements are required for ctype_base
6307   // 339 -&gt; bitmask type required for mask
6308   cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
6309 }
6310 </pre>
6311 </blockquote>
6312
6313
6314
6315 <p><b>Proposed resolution:</b></p>
6316 <p>Informally, we have three choices:</p> 
6317 <ol>
6318 <li>Require that the enumerators are disjoint (except for alnum and
6319 graph)</li>
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
6322 and print)</li>
6323 <li>Explicitly leave this unspecified, which the result that the above
6324 program is not portable.</li>
6325 </ol>
6326
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
6329 change.</p>
6330
6331
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>
6338
6339
6340
6341
6342
6343 <hr>
6344 <h3><a name="357"></a>357. &lt;cmath&gt; 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>
6350 <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.
6354 </p>
6355
6356 <p>
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.
6360 </p>
6361
6362 <p>
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."
6367 </p>
6368
6369 <p>
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.
6375 </p>
6376
6377 <p>
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.
6383 </p>
6384
6385
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>
6389
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>
6395
6396
6397 <p><b>Rationale:</b></p>
6398 <p>Will be fixed as part of more general work in the TR.</p>
6399
6400
6401
6402
6403
6404 <hr>
6405 <h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) 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>
6411 <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).
6415 </p>
6416
6417 <p>
6418 22.2.2.1.2, p12 requires that grouping be checked for all extractors
6419 including that for <tt>void*</tt>.
6420 </p>
6421
6422 <p>
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.)
6426 </p>
6427
6428
6429 <p><b>Proposed resolution:</b></p>
6430 <p>
6431 Change the first sentence of 22.2.2.2.2, p12 from
6432 </p>
6433 <blockquote><p>
6434     Digit grouping is checked. That is, the positions of discarded
6435     separators is examined for consistency with
6436     use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
6437     If they are not consistent then ios_base::failbit is assigned
6438     to err.
6439 </p></blockquote>
6440
6441 <p>to</p>
6442 <blockquote><p>
6443     Except for conversions to void*, digit grouping is checked...
6444 </p></blockquote>
6445
6446
6447
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
6452   should.</p>
6453
6454
6455
6456
6457
6458 <hr>
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>
6465 <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
6469 rationale.
6470 </p>
6471
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>
6479
6480
6481
6482
6483 <p><b>Proposed resolution:</b></p>
6484 <p>In 27.4.4 and 27.4.4.2</p>
6485 <p>Replace</p>
6486 <pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
6487 </pre>
6488 <p>with</p>
6489 <pre>  basic_ostream&lt;charT,traits&gt;* tie();
6490   const basic_ostream&lt;charT,traits&gt;* tie() const;
6491 </pre>
6492
6493 <p>and replace</p>
6494 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
6495 </pre>
6496 <p>with</p>
6497 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
6498   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
6499 </pre>
6500
6501 <p>In 27.5.2 and 27.5.2.3.1</p>
6502 <p>Replace</p>
6503 <pre>  char_type* eback() const;
6504 </pre>
6505 <p>with</p>
6506 <pre>  char_type* eback();
6507   const char_type* eback() const;
6508 </pre>
6509
6510 <p>Replace</p>
6511 <pre>  char_type gptr() const;
6512 </pre>
6513 <p>with</p>
6514 <pre>  char_type* gptr();
6515   const char_type* gptr() const;
6516 </pre>
6517
6518 <p>Replace</p>
6519 <pre>  char_type* egptr() const;
6520 </pre>
6521 <p>with</p>
6522 <pre>  char_type* egptr();
6523   const char_type* egptr() const;
6524 </pre>
6525
6526 <p>In 27.5.2 and 27.5.2.3.2</p>
6527 <p>Replace</p>
6528 <pre>  char_type* pbase() const;
6529 </pre>
6530 <p>with</p>
6531 <pre>  char_type* pbase();
6532   const char_type* pbase() const;
6533 </pre>
6534
6535 <p>Replace</p>
6536 <pre>  char_type* pptr() const;
6537 </pre>
6538 <p>with</p>
6539 <pre>  char_type* pptr();
6540   const char_type* pptr() const;
6541 </pre>
6542
6543 <p>Replace</p>
6544 <pre>  char_type* epptr() const;
6545 </pre>
6546 <p>with</p>
6547 <pre>  char_type* epptr();
6548   const char_type* epptr() const;
6549 </pre>
6550
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>
6552 <p>Replace</p>
6553 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
6554 </pre>
6555 <p>with</p>
6556 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
6557   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
6558 </pre>
6559
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>
6561 <p>Replace</p>
6562 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
6563 </pre>
6564 <p>with</p>
6565 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
6566   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
6567 </pre>
6568
6569
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>
6577
6578
6579
6580
6581
6582 <hr>
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>
6589 <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.
6599 </p>
6600
6601
6602 <p><b>Proposed resolution:</b></p>
6603 <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.
6608 </p>
6609
6610
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>
6614
6615
6616
6617
6618
6619 <hr>
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>
6626 <p>
6627 21.4.6.6 [string::replace] basic_string::replace, second
6628 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
6629 5).
6630 </p>
6631
6632 <p>
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.
6636 </p>
6637
6638
6639 <p><b>Proposed resolution:</b></p>
6640
6641
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
6646   notified.</p>
6647
6648
6649
6650
6651
6652 <hr>
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>
6659
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>
6669
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>
6674
6675 <p>Is this inconsistent?</p>
6676
6677
6678
6679 <p><b>Proposed resolution:</b></p>
6680
6681
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.
6686 </p>
6687
6688
6689
6690
6691
6692 <hr>
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>
6698 <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".
6702 </p>
6703
6704 <p>
6705 Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
6706 should return "unsigned".
6707 </p>
6708
6709
6710
6711 <p><b>Proposed resolution:</b></p>
6712
6713
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
6719 checks.</p>
6720
6721
6722
6723
6724
6725 <hr>
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>
6732 <p>
6733 Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
6734 "Then throws length_error if size() &gt;= npos - rlen."
6735 </p>
6736
6737 <p>
6738 Related to DR 83, this sentence should probably be removed.
6739 </p>
6740
6741
6742 <p><b>Proposed resolution:</b></p>
6743
6744
6745 <p><b>Rationale:</b></p><p>This requirement is redundant but correct.  No change is
6746 needed.</p>
6747
6748
6749
6750
6751 <hr>
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>
6759 <p>
6760 I think there is a problem with 22.1.1, p6 which says that
6761 </p>
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.
6765 </pre>
6766 <p>
6767 and 22.1.1.2, p4:
6768 </p>
6769 <pre>    const locale&amp; operator=(const locale&amp; other) throw();
6770
6771     -4- Effects: Creates a copy of other, replacing the current value.
6772 </pre>
6773 <p>
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
6777 </p>
6778 <pre>    std::locale loc ("de_DE");
6779     const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
6780     loc = std::locale ("en_US");
6781     const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
6782 </pre>
6783 <p>
6784 Is r0 really supposed to be preserved and destroyed only when loc goes
6785 out of scope?
6786 </p>
6787
6788
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
6792   closed.
6793 ]</i></p>
6794
6795
6796
6797
6798
6799
6800 <hr>
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>
6807 <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:
6812 </p>
6813
6814 <ol>
6815 <li>
6816   the conditions under which the functions terminate
6817 </li>
6818 <li>
6819   precisely when the functions return ok
6820 </li>
6821 <li>
6822   precisely when the functions return partial
6823 </li>
6824 <li>
6825   the full set of conditions when the functions return error
6826 </li>
6827 </ol>
6828
6829 <ol>
6830 <li>
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)?
6838 </li>
6839 <li>
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).
6846 </li>
6847 <li>
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).
6852 </li>
6853 <li>
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).
6861 </li>
6862 </ol>
6863 <p>
6864 Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
6865 </p>
6866 <blockquote><p>
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."
6872 </p></blockquote>
6873 <p>
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.
6881 </p>
6882 <p>
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.
6889 </p>
6890 <p>
6891 Could it be that the intended qualifying condition was actually
6892 (from_next != from_end), i.e., that the sentence was supposed
6893 to read
6894 </p>
6895 <blockquote><p>
6896     "A return value of partial, if (from_next != from_end),..."
6897 </p></blockquote>
6898 <p>
6899 which would make perfect sense, since, as far as I understand it,
6900 partial can only occur if (from_next != from_end)?
6901 </p>
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>
6914
6915
6916 <p><i>[
6917 2009-07 Frankfurt
6918 ]</i></p>
6919
6920
6921 <blockquote>
6922 <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 &lt;-&gt; UTF-8 conversions.
6927 </p>
6928 <p>
6929 NAD without prejudice. Will reopen if proposed resolution is supplied.
6930 </p>
6931 </blockquote>
6932
6933
6934
6935 <p><b>Proposed resolution:</b></p>
6936
6937
6938
6939
6940 <hr>
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>
6948 <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?
6954 </p>
6955
6956 <p>
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&lt;my_iterator,
6963 my_predicate&amp;&gt;</tt>.  The question is whether implementation
6964 are required to accept this, or whether this is ill-formed because
6965 my_predicate&amp; is not CopyConstructible.
6966 </p>
6967
6968 <p>
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.
6973 </p>
6974 <p><i>[
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
6979 not be allowed.
6980 ]</i></p>
6981
6982 <p><i>[
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.
6998 ]</i></p>
6999
7000
7001
7002 <p><b>Proposed resolution:</b></p>
7003 <p>
7004 Recommend NAD.
7005 </p>
7006
7007
7008 <p><b>Rationale:</b></p>
7009 <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.
7013 </p>
7014
7015
7016
7017
7018
7019 <hr>
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>
7026 <p>
7027 Practice with std::complex&lt;&gt; and the associative containers
7028 occasionally reveals artificial and distracting issues with constructs
7029 resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
7030 </p>
7031
7032 <p>
7033 The main reason for the above to fail is the absence of an approriate
7034 definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
7035 the definition of the primary template std::less&lt;&gt; in terms of
7036 operator&lt;.
7037 </p>
7038
7039 <p>
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&lt; operating on the datatype
7043 std::complex&lt;T&gt;.  That is fine. However, that reasoning does not carry
7044 over to std::less&lt;T&gt; which is used, among other things, by associative
7045 containers as an ordering useful to meet complexity requirements.
7046 </p>
7047
7048 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
7049
7050 <p><i>[
7051 Pre Bellevue: Reopened at the request of Alisdair.
7052 ]</i></p>
7053
7054
7055 <p><i>[
7056 Bellevue:
7057 ]</i></p>
7058
7059
7060 <blockquote>
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&lt; isn't defined can simply provide their own comparison function
7069 object. NAD
7070 </blockquote>
7071
7072
7073 <p><b>Proposed resolution:</b></p>
7074 <p>Informally: Add a specialization of std::less for std::complex.</p>
7075
7076
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&lt;</tt> isn't defined can simply
7085 provide their own comparison function object.</p>
7086
7087
7088
7089
7090
7091 <hr>
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>
7098 <p>
7099 The CopyConstructible requirements in Table 30 state that for an
7100 object t of type T (where T is CopyConstructible), the expression &amp;t
7101 returns the address of t (with type T*). This requirement is overly
7102 strict, in that it disallows types that overload operator&amp; 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&amp; is overloaded for a Boost.Lambda function object to return
7105 another function object.
7106 </p>
7107
7108 <p>Example:</p>
7109
7110 <pre>  std::vector&lt;int&gt; u, v;
7111   int x;
7112   // ...
7113   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
7114 </pre>
7115
7116 <p>
7117 _1 * x returns an unnamed function object with operator&amp; 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.
7122 </p>
7123
7124 <p>
7125 For reference, the address of an object can be retrieved without using
7126 the address-of operator with the following function template:
7127 </p>
7128
7129 <pre>  template &lt;typename T&gt; T* addressof(T&amp; v)
7130   {
7131     return reinterpret_cast&lt;T*&gt;(
7132          &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
7133   }
7134 </pre>
7135
7136 <p>
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
7139 change.
7140 </p>
7141
7142
7143 <p><b>Proposed resolution:</b></p>
7144 <p>
7145 Remove the last two rows of Table 30, eliminating the requirements
7146 that &amp;t and &amp;u return the address of t and u, respectively.
7147 </p>
7148
7149
7150 <p><b>Rationale:</b></p>
7151 <p>This was a deliberate design decision.  Perhaps it should be
7152    reconsidered for C++0x. </p>
7153
7154
7155
7156
7157
7158 <hr>
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>
7165
7166 <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".
7170 </p>
7171
7172 <p>
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).
7177 </p>
7178
7179 <p>
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).
7183 </p>
7184
7185 <p>Consider the following example:</p>
7186 <pre>   #include &lt;iostream&gt;
7187    #include &lt;fstream&gt;
7188    #include &lt;iterator&gt;
7189    using namespace std;
7190
7191    int main() {
7192     ifstream file1("file1.txt"), file2("file2.txt");
7193     istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
7194     cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
7195     cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
7196     cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
7197     return 0;
7198    }
7199 </pre>
7200
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>
7203
7204 <p>However, it is unlikely that *f1 will give the same value as *f2 except
7205 by accident.</p>
7206
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>
7211
7212
7213 <p><b>Proposed resolution:</b></p>
7214
7215
7216 <p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
7217
7218
7219
7220
7221
7222
7223 <hr>
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>
7230 <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.
7234 </p>
7235 <p>
7236 Can do_in()/do_out() produce output characters without consuming input 
7237 characters as a result of operation on state?
7238 </p>
7239
7240
7241 <p><b>Proposed resolution:</b></p>
7242 <p>
7243 Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals], 
7244 paragraph 3:
7245 </p>
7246
7247 <p>
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]
7250 </p>
7251
7252
7253 <p><b>Rationale:</b></p>
7254 <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
7259 they succeed.
7260 </p>
7261
7262 <p>
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.
7271 </p>
7272
7273
7274 <p><i>[
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
7278 ]</i></p>
7279
7280
7281
7282
7283
7284
7285 <hr>
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>
7291 <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.
7295 </p>
7296 <p>
7297 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
7298 functions:
7299 </p>
7300 <pre>     ... If the generation fails, then the formatted output function
7301      does setstate(ios::failbit), which might throw an exception.
7302 </pre>
7303 <p>
7304 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
7305 </p>
7306 <p>
7307      ... The formatting conversion occurs as if it performed the
7308      following code fragment:
7309 </p>
7310 <pre>     bool failed =
7311          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
7312          &gt; &gt;
7313          (getloc()).put(*this, *this, fill(), val). failed();
7314
7315      ... If failed is true then does setstate(badbit) ...
7316 </pre>
7317 <p>
7318 The original intent of the text, according to Jerry Schwarz (see
7319 c++std-lib-10500), is captured in the following paragraph:
7320 </p>
7321 <p>
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
7328 you'll succeed.
7329 </p>
7330 <p>
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().
7337 </p>
7338 <p>
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).
7346 </p>
7347 <p>
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.
7352 </p>
7353 <p>
7354 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
7355 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
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.
7359 </p>
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>
7376
7377
7378 <p><i>[
7379 2009-07 Frankfurt
7380 ]</i></p>
7381
7382
7383 <blockquote>
7384 NAD. This issue is already fixed.
7385 </blockquote>
7386
7387
7388
7389 <p><b>Proposed resolution:</b></p>
7390
7391
7392 <p><b>Rationale:</b></p>
7393
7394
7395
7396
7397
7398
7399 <hr>
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>
7406     <p>
7407 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
7408     </p>
7409     <p>
7410 27.6.2.3, p4 says this about the ostream::sentry dtor:
7411     </p>
7412     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
7413         is true, calls os.flush().
7414     </pre>
7415     <p>
7416 27.6.2.6, p7 that describes ostream::flush() says:
7417     </p>
7418     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
7419         If that function returns ?-1 calls setstate(badbit) (which
7420         may throw ios_base::failure (27.4.4.3)).
7421     </pre>
7422     <p>
7423 That seems like a defect, since both pubsync() and setstate() can
7424 throw an exception. 
7425     </p>
7426 <p><i>[
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.
7434 ]</i></p>
7435
7436
7437 <p><i>[
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.
7439 ]</i></p>
7440
7441
7442 <p><i>[
7443 2009-07 Frankfurt
7444 ]</i></p>
7445
7446
7447 <blockquote>
7448 <p>
7449 Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~sentry().
7450 </p>
7451 </blockquote>
7452
7453 <p><i>[
7454 2009-10-13 Daniel adds:
7455 ]</i></p>
7456
7457
7458 <blockquote>
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
7460 of this issue.
7461 </blockquote>
7462
7463 <p><i>[
7464 2009 Santa Cruz:
7465 ]</i></p>
7466
7467
7468 <blockquote>
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>.
7470 </blockquote>
7471
7472 <p><i>[
7473 2010-03-06 Martin updates wording.
7474 ]</i></p>
7475
7476
7477 <p><i>[
7478 2010 Pittsburgh:
7479 ]</i></p>
7480
7481
7482 <blockquote>
7483 Moved to NAD Editorial.
7484 </blockquote>
7485
7486
7487
7488 <p><b>Rationale:</b></p>
7489 <p>
7490 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>.
7491 </p>
7492
7493
7494 <p><b>Proposed resolution:</b></p>
7495 <p>
7496 Add after 27.7.2.4 [ostream::sentry] p17:
7497 </p>
7498
7499 <blockquote>
7500 <pre>~sentry();
7501 </pre>
7502 <blockquote>
7503 <p>
7504 -17- If <tt>(os.flags() &amp; ios_base::unitbuf)</tt>
7505 is <tt>true</tt>, calls <tt>os.flush()</tt>.
7506 </p>
7507
7508 <p><ins>
7509 <i>Throws:</i> Nothing.
7510 </ins></p>
7511 </blockquote>
7512 </blockquote>
7513
7514
7515
7516
7517
7518 <hr>
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>
7525     <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).
7532     </p>
7533     <p>
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):
7537     </p>
7538     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7539     get (char_type*, streamsize, char_type);
7540     </pre>
7541     <p>
7542     Also sets failbit if it fails to extract any characters.
7543     </p>
7544     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7545     get (char_type*, streamsize);
7546     </pre>
7547     <p>
7548     Also sets failbit if it fails to extract any characters.
7549     </p>
7550     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7551     getline (char_type*, streamsize, char_type);
7552     </pre>
7553     <p>
7554     Also sets failbit if it fails to extract any characters.
7555     </p>
7556     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7557     getline (char_type*, streamsize);
7558     </pre>
7559     <p>
7560     Also sets failbit if it fails to extract any characters.
7561     </p>
7562     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7563     ignore (int, int_type);
7564     </pre>
7565     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7566     read (char_type*, streamsize);
7567     </pre>
7568     <p>
7569     Also sets failbit if it encounters end-of-file.
7570     </p>
7571     <pre>    streamsize readsome (char_type*, streamsize);
7572     </pre>
7573
7574     <p>
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):
7581     </p>
7582     <pre>    int_type get();
7583     </pre>
7584     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7585     get (char_type&amp;);
7586     </pre>
7587     <p>
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):
7593     </p>
7594     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7595     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
7596     </pre>
7597     <pre>    basic_istream&lt;charT, traits&gt;&amp;
7598     get (basic_streambuf&lt;charT, traits&gt;&amp;);
7599     </pre>
7600     <p>
7601 This function sets no bits (all implementations except for
7602 STLport and Classic Iostreams set eofbit when they encounter
7603 end-of-file):
7604     </p>
7605     <pre>    int_type peek ();
7606     </pre>
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>
7613
7614 <p><i>[
7615 2009-07 Frankfurt
7616 ]</i></p>
7617
7618
7619 <blockquote>
7620 Moved to NAD.  See 27.7.1.1 [istream] p3.
7621 </blockquote>
7622
7623
7624
7625 <p><b>Proposed resolution:</b></p>
7626
7627
7628
7629
7630 <hr>
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>
7637     <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
7644 exceptions().
7645     </p>
7646     <p>
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&lt;charT&gt;
7652 ::widen() during any other input operation (say, from within
7653 a call to num_get&lt;charT&gt;::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.
7656     </p>
7657   
7658
7659 <p><b>Proposed resolution:</b></p>
7660
7661
7662 <p><b>Rationale:</b></p>
7663 <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.
7670 </p>
7671
7672
7673
7674
7675
7676
7677 <hr>
7678 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; 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>
7684 <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.
7687 </p>
7688
7689 <p>
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&lt;&gt; in the default
7695 constructor.  As a result, code like
7696 </p>
7697 <blockquote><pre>  std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
7698   v.reserve(1000);
7699 </pre></blockquote>
7700 <p>
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.
7705 </p>
7706
7707 <p>
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.
7714 </p>
7715
7716 <p>
7717 One question is whether the standard iterator adaptors have defined
7718 copy semantics.  Another is whether they have defined destructor
7719 semantics: is
7720 </p>
7721 <blockquote><pre>  { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
7722 </pre></blockquote>
7723 <p>
7724 undefined too?
7725 </p>
7726
7727 <p>
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&lt;T&gt; constructor is actually required to execute
7734 T(), and so copying is defined if the result of T() is copyable.
7735 </p>
7736
7737 <p>
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.
7741 </p>
7742
7743 <p>
7744 The issue was whether 
7745 </p>
7746 <blockquote><pre>  reverse_iterator() { }
7747 </pre></blockquote>
7748 <p>
7749 is allowed, vs. 
7750 </p>
7751 <blockquote><pre>  reverse_iterator() : current() { }
7752 </pre></blockquote>
7753
7754 <p>
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.
7758 </p>
7759
7760 <p>
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
7763 types.
7764 </p>
7765
7766 <p>
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
7770 </p>
7771 <blockquote><pre>  template &lt;typename Iterator&gt;
7772     void f() { std::vector&lt;Iterator&gt;  v(7); } 
7773 </pre></blockquote>
7774 <p>
7775 evoke undefined behavior for some conforming iterator definitions?
7776 I think it does, now, because vector&lt;&gt; will destroy those singular
7777 iterator values, and that's explicitly disallowed.
7778 </p>
7779
7780 <p>
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.
7786 </p>
7787
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>
7789 <p><i>[
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.
7797 ]</i></p>
7798
7799
7800 <p><i>[
7801 2009-05-10 Alisdair provided wording.
7802 ]</i></p>
7803
7804
7805 <blockquote>
7806 The comments regarding destroying singular iterators have already been
7807 resolved.  That just leaves copying (with moving implied).
7808 </blockquote>
7809
7810 <p><i>[
7811 2009-07 Frankfurt
7812 ]</i></p>
7813
7814
7815 <blockquote>
7816 <p>
7817 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>.
7818 </p>
7819 <p>
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
7823 "value."
7824 </p>
7825 <p>
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.
7830 </p>
7831 <p>
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.
7835 </p>
7836 <p>
7837 Move to Review after Alisdair updates the wording.
7838 </p>
7839 </blockquote>
7840
7841 <p><i>[
7842 2009-07-31 Alisdair revised wording:
7843 ]</i></p>
7844
7845
7846 <p><i>[
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>
7849 ]</i></p>
7850
7851
7852 <p><i>[
7853 2009-10-14 Daniel adds:
7854 ]</i></p>
7855
7856
7857 <blockquote>
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.
7860 </blockquote>
7861
7862 <p><i>[
7863 2009-10 Santa Cruz:
7864 ]</i></p>
7865
7866
7867 <blockquote>
7868 Moved to Open. Alisdair will provide improved wording to make
7869 this have "value semantics" and otherwise behave like a valid iterator.
7870 </blockquote>
7871
7872 <p><i>[
7873 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
7874 ]</i></p>
7875
7876
7877
7878
7879 <p><b>Rationale:</b></p>
7880 <p>
7881 Solved by
7882 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
7883 </p>
7884
7885
7886 <p><b>Proposed resolution:</b></p>
7887 <p>
7888 Add a new paragrpah to Iterator concepts 24.2 [iterator.requirements] after para 5 (the one describing
7889 singular iterators)
7890 </p>
7891 <blockquote>
7892 <p>
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.
7908 </p>
7909 <p><ins>
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
7917 <i>end note</i>]
7918 </ins></p>
7919
7920
7921 </blockquote>
7922
7923
7924
7925
7926
7927
7928 <hr>
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>
7935 <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&lt;wchar_t&gt; 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. 
7944 </p>
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>
7954
7955
7956 <p><i>[
7957 2009-07 Frankfurt
7958 ]</i></p>
7959
7960
7961 <blockquote>
7962 NAD. The behavior is specified for all of the facets that an
7963 implementation is required to provide, for the basic character set.
7964 </blockquote>
7965
7966
7967
7968 <p><b>Proposed resolution:</b></p>
7969
7970
7971
7972
7973 <hr>
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>
7980 <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.
7984 </p>
7985
7986 <p>
7987 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
7988 </p>
7989
7990 <p>
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
7994 object throws.
7995 </p>
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>
8003
8004
8005 <p><i>[
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.
8007 ]</i></p>
8008
8009
8010 <p><i>[
8011 2009-07 Frankfurt
8012 ]</i></p>
8013
8014
8015 <blockquote>
8016 Moved to NAD, no consensus for change.
8017 </blockquote>
8018
8019
8020
8021 <p><b>Proposed resolution:</b></p>
8022
8023
8024
8025
8026 <hr>
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>
8033 <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.
8042 </p>
8043
8044 <p>
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>.
8052 </p>
8053
8054 <p><i>[
8055 2009-07 Frankfurt
8056 ]</i></p>
8057
8058
8059 <blockquote>
8060 NAD. Option B is already in the Working Draft.
8061 </blockquote>
8062
8063
8064
8065 <p><b>Proposed resolution:</b></p>
8066 <p>
8067 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
8068 </p>
8069
8070 <blockquote>
8071 <pre>basic_streambuf(const basic_streambuf&amp; sb);
8072 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
8073 </pre>
8074 </blockquote>
8075
8076 <p>Insert after 27.5.2.1, paragraph 2:</p>
8077 <blockquote>
8078 <pre>basic_streambuf(const basic_streambuf&amp; sb);
8079 </pre>
8080
8081 <p>Constructs a copy of sb.</p>
8082 <p>Postcondtions:</p>
8083 <pre>                eback() == sb.eback()
8084                 gptr()  == sb.gptr()
8085                 egptr() == sb.egptr()
8086                 pbase() == sb.pbase()
8087                 pptr()  == sb.pptr()
8088                 epptr() == sb.epptr()
8089                 getloc() == sb.getloc()
8090 </pre>
8091
8092 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
8093 </pre>
8094
8095 <p>Assigns the data members of sb to this.</p>
8096
8097 <p>Postcondtions:</p>
8098 <pre>                eback() == sb.eback()
8099                 gptr()  == sb.gptr()
8100                 egptr() == sb.egptr()
8101                 pbase() == sb.pbase()
8102                 pptr()  == sb.pptr()
8103                 epptr() == sb.epptr()
8104                 getloc() == sb.getloc()
8105 </pre>
8106
8107 <p>Returns: *this.</p>
8108 </blockquote>
8109
8110 <p>27.7.1 [lib.stringbuf]:</p>
8111
8112 <p><b>Option A:</b></p>
8113
8114 <blockquote>
8115 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
8116
8117 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
8118 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
8119 </pre>
8120 </blockquote>
8121
8122 <p><b>Option B:</b></p>
8123
8124 <blockquote>
8125 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
8126
8127 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
8128 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
8129 </pre>
8130
8131 <p>27.7.1.1, insert after paragraph 4:</p>
8132
8133 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
8134
8135 <p>
8136 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
8137 </p>
8138
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()
8145 </pre>
8146
8147 <p>
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().
8149 </p>
8150
8151 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
8152 <p>
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().
8154 </p>
8155 </blockquote>
8156
8157 <p>27.8.1.1 [lib.filebuf]</p>
8158
8159 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
8160
8161 <blockquote>
8162 <pre>private:
8163   basic_filebuf(const basic_filebuf&amp;);             // not defined
8164   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
8165 </pre>
8166 </blockquote>
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>
8173
8174
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.
8185 ]</i></p>
8186
8187
8188 <p><i>[
8189 2007-01-12, Howard:
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.
8198 ]</i></p>
8199
8200
8201
8202
8203 <p><b>Rationale:</b></p>
8204 <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
8209 standard.
8210 </p>
8211
8212 <p>
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
8220 into account.
8221 </p>
8222
8223 <p>
8224 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
8225 basic_filebuf.
8226 </p>
8227
8228
8229
8230
8231
8232
8233 <hr>
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>
8240
8241 <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 &gt;= 0) holds and
8245 aborts the test.
8246 </p>
8247
8248 <p>
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).
8253 </p>
8254
8255 <p><i>[
8256 2009-07 Frankfurt
8257 ]</i></p>
8258
8259
8260 <blockquote>
8261 <p>
8262 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.
8263 </p>
8264 <p>
8265 Move to NAD Future.
8266 </p>
8267 </blockquote>
8268
8269
8270
8271 <p><b>Proposed resolution:</b></p>
8272 <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 &gt;= 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
8277 ostream::write().
8278 </p>
8279
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>
8284
8285
8286
8287
8288
8289
8290 <hr>
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>
8296
8297 <p>
8298 The text in 17.3.1.1, p1 says:
8299 <br>
8300
8301 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
8302 paragraphs are normative."
8303 <br>
8304
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).
8309 <br><br>
8310
8311 List 1 -- Examples of (presumably) normative Notes:
8312 <br>
8313
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>
8322 <br>
8323
8324 List 2 -- Examples of (presumably) informative Notes:
8325 <br>
8326
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>
8333 <br>
8334
8335 List 3 -- Examples of Notes that are not clearly either normative
8336 or informative:
8337 <br>
8338
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>
8342 <br>
8343
8344 None of these lists is meant to be exhaustive.
8345 </p>
8346
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.
8353 ]</i></p>
8354
8355
8356 <p><i>[
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.
8360 ]</i></p>
8361
8362
8363 <p><i>[
8364 post San Francisco:  Howard: reopened, needs attention.
8365 ]</i></p>
8366
8367
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>
8371
8372
8373 <p><i>[
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.
8377 ]</i></p>
8378
8379
8380 <p><i>[
8381 Batavia (2009-05):
8382 ]</i></p>
8383
8384 <blockquote>
8385 <p>
8386 A spot-check of List 2 suggests the issue is still relevant,
8387 and a review of List 3 still seems called-for.
8388 </p>
8389 <p>
8390 Move to NAD Editorial.
8391 </p>
8392 </blockquote>
8393
8394
8395
8396 <p><b>Proposed resolution:</b></p>
8397
8398
8399
8400
8401 <hr>
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>
8409         <p>
8410
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 &amp;&amp; exceptions() == badbit)
8416 holds would not result in an exception being thrown.
8417
8418         </p>
8419     
8420     <p><b>Proposed resolution:</b></p>
8421         <p>
8422
8423 The text ought to be changed from
8424 <br>
8425
8426 "If (rdstate() &amp; exceptions()) == 0, returns. ..."
8427 <br>
8428
8429 to
8430 <br>
8431
8432 "If (state &amp; exceptions()) == 0, returns. ..."
8433         </p>
8434
8435
8436 <p><b>Rationale:</b></p>
8437
8438
8439
8440
8441
8442
8443 <hr>
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>
8449 <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.
8462 </p>
8463
8464
8465 <p><b>Proposed resolution:</b></p>
8466
8467
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>
8471
8472
8473
8474
8475
8476 <hr>
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>
8483 <p>
8484 Given:
8485 </p>
8486 <pre>void f(int) {}
8487 void(*g)(int) = f;
8488 cout &lt;&lt; g;
8489 </pre>
8490
8491 <p>
8492 (with the expected #include and usings), the value printed is a rather
8493 surprising "true". Rather useless too.
8494 </p>
8495
8496 <p>The standard defines:</p>
8497
8498 <pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
8499
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.
8504 </p>
8505
8506 <p>There should be an analogous inserter that prints the address of a
8507   function pointer.</p>
8508
8509
8510 <p><b>Proposed resolution:</b></p>
8511
8512
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>
8517
8518
8519
8520
8521
8522 <hr>
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>
8534
8535 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>.</p>
8536
8537 <pre>        ctype_base
8538         ctype
8539         ctype_byname
8540         ctype&lt;char&gt;
8541         ctype_byname&lt;char&gt;
8542         codecvt_base
8543         codecvt
8544         codecvt_byname
8545         num_get
8546         num_put
8547         numpunct
8548         numpunct_byname
8549         collate
8550         collate_byname
8551         time_base
8552         time_get
8553         time_get_byname
8554         time_put
8555         time_put_byname
8556         money_get
8557         money_put
8558         money_base
8559         moneypunct
8560         moneypunct_byname
8561         messages_base
8562         messages
8563         messages_byname
8564 </pre>
8565
8566
8567
8568 <p><b>Proposed resolution:</b></p>
8569
8570
8571 <p><b>Rationale:</b></p>
8572 <p>The copy constructor in the base class is private.</p>
8573
8574
8575
8576
8577
8578 <hr>
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>
8584 <p>
8585 Operations like <tt>pow</tt> and <tt>exp</tt> on
8586 <tt>complex&lt;T&gt;</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>?
8590 </p>
8591
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>
8596
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>
8604
8605
8606
8607 <p><b>Proposed resolution:</b></p>
8608
8609
8610 <p><b>Rationale:</b></p>
8611 <p>If you instantiate std::complex for user-defined types, all bets
8612 are off.</p>
8613
8614
8615
8616
8617
8618 <hr>
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>
8625 <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?
8630 </p>
8631
8632 <p>
8633 The standard appears to be silent on both questions.
8634 </p>
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
8642 reachability.
8643 ]</i></p>
8644
8645
8646 <p><i>[
8647 2009-07 Frankfurt
8648 ]</i></p>
8649
8650
8651 <blockquote>
8652 Daniel volunteered to work on this.
8653 </blockquote>
8654
8655 <p><i>[
8656 2009-09-20 Daniel provided wording.
8657 ]</i></p>
8658
8659
8660 <p><i>[
8661 2009-10 Santa Cruz:
8662 ]</i></p>
8663
8664
8665 <blockquote>
8666 Leave as Open. Alisdair has volunteered to refine the wording.
8667 </blockquote>
8668
8669 <p><i>[
8670 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
8671 ]</i></p>
8672
8673
8674
8675
8676 <p><b>Rationale:</b></p>
8677 <p>
8678 Solved by
8679 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
8680 </p>
8681
8682
8683 <p><b>Proposed resolution:</b></p>
8684 <p>
8685 Insert a new paragraph between 24.2 [iterator.requirements]/7+8:
8686 </p>
8687
8688 <blockquote>
8689 <p>
8690 [..] The result of the application of functions in the library to invalid
8691 ranges is undefined.
8692 </p>
8693
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
8696 were obtained
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>
8700 </p>
8701
8702 </blockquote>
8703
8704
8705
8706
8707
8708
8709 <hr>
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>
8717 <p>
8718 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
8719 </p>
8720 <pre>    time_get&lt;char,InputIterator&gt;
8721     time_get_byname&lt;char,InputIterator&gt;
8722     time_get&lt;wchar_t,OutputIterator&gt;
8723     time_get_byname&lt;wchar_t,OutputIterator&gt;
8724 </pre>
8725
8726 <p>
8727 The second argument to the last two should be InputIterator, not
8728 OutputIterator.
8729 </p>
8730
8731
8732 <p><b>Proposed resolution:</b></p>
8733 <p>
8734 Change the second template argument to InputIterator.
8735 </p>
8736
8737
8738 <p><b>Rationale:</b></p>
8739
8740
8741
8742
8743
8744
8745 <hr>
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>
8754
8755 <pre>    iterator find(const key_type&amp; x) const;
8756     const_iterator find(const key_type&amp; x) const;
8757 </pre>
8758
8759 <p>
8760 which is consistent with the table of associative container requirements.
8761 But set/multiset have:
8762 </p>
8763 <pre>    iterator find(const key_type&amp;) const;
8764 </pre>
8765
8766 <p>
8767 set/multiset should look like map/multimap, and honor the requirements
8768 table, in this regard.
8769 </p>
8770
8771
8772 <p><b>Proposed resolution:</b></p>
8773
8774
8775 <p><b>Rationale:</b></p>
8776
8777
8778
8779
8780
8781
8782 <hr>
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);
8794 </pre>
8795
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);
8800 </pre>
8801
8802
8803
8804 <p><b>Proposed resolution:</b></p>
8805 <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.
8809 </p>
8810
8811
8812 <p><b>Rationale:</b></p>
8813
8814
8815
8816
8817
8818
8819 <hr>
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&lt;class Facet&gt;
8827     locale::combine(const locale&amp;) const;
8828 </pre>
8829 <p>
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
8833 standard facets.
8834 </p>
8835
8836 <p><i>[
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.
8845 ]</i></p>
8846
8847
8848
8849
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>
8855
8856
8857
8858
8859
8860 <hr>
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);
8869 </pre>
8870
8871 <p>should be supplemented with the overload:</p>
8872
8873 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
8874 </pre>
8875
8876 <p>
8877 Depending on the operating system, one of these forms is fundamental and
8878 the other requires an implementation-defined mapping to determine the
8879 actual filename.
8880 </p>
8881
8882 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
8883   provide wording.]</i></p>
8884
8885
8886 <p><i>[
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>.
8889 ]</i></p>
8890
8891 <p>
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.
8896 </p>
8897 <p>
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.
8901 </p>
8902 <p>
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.
8905 </p>
8906 <p>
8907 Implementors are free to add specific overloads for non-char character
8908 types.
8909 </p>
8910
8911 <p><i>[
8912 Martin adds pre-Sophia Antipolis:
8913 ]</i></p>
8914
8915
8916 <blockquote>
8917 Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
8918 </blockquote>
8919
8920 <p><i>[
8921 Sophia Antipolis:
8922 ]</i></p>
8923
8924
8925 <blockquote>
8926 <p>
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.
8930 </p>
8931 <p>
8932 The TR2 filesystem library is a more complete solution, but is not available soon.
8933 </p>
8934 </blockquote>
8935
8936 <p><i>[
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.
8940 ]</i></p>
8941
8942
8943
8944
8945 <p><b>Proposed resolution:</b></p>
8946
8947 <p>Change from:</p>
8948 <blockquote>
8949 <pre>basic_filebuf&lt;charT,traits&gt;* open(
8950     const char* s,
8951     ios_base::openmode mode );
8952 </pre>
8953
8954 <p>
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>
8959 </blockquote>
8960
8961 <p>to:</p>
8962
8963 <blockquote>
8964 <pre>basic_filebuf&lt;charT,traits&gt;* open(
8965     const char* s,
8966     ios_base::openmode mode );
8967
8968 basic_filebuf&lt;charT,traits&gt;* open(
8969     const wchar_t* ws,
8970     ios_base::openmode mode );
8971 </pre>
8972
8973 <p>
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.
8980 </p>
8981
8982 <p>
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.)
8987 </p>
8988 </blockquote>
8989
8990
8991
8992 <p><b>Rationale:</b></p>
8993 <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>
9000
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>
9006
9007
9008 <p><i>[
9009 post Bellevue:
9010 ]</i></p>
9011
9012
9013 <blockquote>
9014 <p>
9015 Move again to Ready.
9016 </p>
9017 <p>
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.
9021 </p>
9022 <p>
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.
9028 </p>
9029 <p>
9030 If more of the Lillehammer questions come back, they should be
9031 introduced as separate issues.
9032 </p>
9033 </blockquote>
9034
9035 <p><i>[
9036 San Francisco:
9037 ]</i></p>
9038
9039
9040 <blockquote>
9041 Some existing implementations provide overload already. Expected
9042 filesystem "path" object overloads neatly, without surprises; implying
9043 NAD.
9044 </blockquote>
9045
9046
9047
9048
9049
9050
9051
9052 <hr>
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>
9059 <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
9063 for unsigned types.
9064 </p>
9065
9066 <p><i>[
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.
9070 ]</i></p>
9071
9072
9073 <p><i>[
9074 Post Summit Alisdair adds:
9075 ]</i></p>
9076
9077
9078 <blockquote>
9079 <p>
9080 This issue refers to a requirements table we have removed.
9081 </p>
9082 <p>
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.
9086 </p>
9087 </blockquote>
9088
9089 <p><i>[
9090 Batavia (2009-05):
9091 ]</i></p>
9092
9093 <blockquote>
9094 <p>
9095 We agree with Alisdair's observations.
9096 </p>
9097 <p>
9098 Move to NAD.
9099 </p>
9100 </blockquote>
9101
9102 <p><i>[
9103 2009-07 Frankfurt:
9104 ]</i></p>
9105
9106
9107 <blockquote>
9108 <p>
9109 Need to look at again without concepts.
9110 </p>
9111 <p>
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
9115 is never unsigned.
9116 </p>
9117 </blockquote>
9118
9119 <p><i>[
9120 2009-10 Santa Cruz:
9121 ]</i></p>
9122
9123
9124 <blockquote>
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.
9128 </blockquote>
9129
9130
9131
9132 <p><b>Proposed resolution:</b></p>
9133 <p>
9134 To remove this limitation, I suggest to change the
9135 operational semantics for this column to:
9136 </p>
9137 <blockquote><pre>    { Distance m = n;
9138       if (m &gt;= 0)
9139         while (m--) --r;
9140       else
9141         while (m++) ++r;
9142       return r; }
9143 </pre></blockquote>
9144
9145
9146
9147
9148
9149
9150 <hr>
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>
9164
9165 <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:
9172 </p>
9173
9174 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
9175   {
9176       const unsigned wi = unsigned (wc);
9177
9178       if (wi &gt; UCHAR_MAX)
9179           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
9180                  dflt : do_narrow (wc, dflt);
9181
9182       if (narrow_ [wi] &lt; 0) {
9183          const char nc = do_narrow (wc, dflt);
9184          if (nc == dflt)
9185              return dflt;
9186          narrow_ [wi] = nc;
9187       }
9188
9189       return char (narrow_ [wi]);
9190   }
9191 </pre>
9192
9193 <p>
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&lt;charT&gt;::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.
9210 </p>
9211
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>
9218
9219
9220 <p><i>[
9221 2009-07 Frankfurt
9222 ]</i></p>
9223
9224
9225 <blockquote>
9226 NAD. The standard is clear enough as written.
9227 </blockquote>
9228
9229
9230
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>
9234 <ol>
9235   <li> call widen on the atoms and compare (either by using
9236       operator== or char_traits&lt;charT&gt;::eq) the input with
9237       the widened atoms, or</li>
9238   <li> call narrow on the input and compare the narrow input
9239       with the atoms</li>
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>
9243 </ol>
9244
9245
9246
9247
9248
9249 <hr>
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>
9255 <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.
9267 </p>
9268
9269 <p>
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.
9275 </p>
9276
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>
9283
9284
9285 <p><i>[
9286 Batavia:  Send to core with our recommendation that we should permit deferred
9287 destruction but not require it.
9288 ]</i></p>
9289
9290
9291 <p><i>[
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:
9298 ]</i></p>
9299
9300
9301 <blockquote><pre>#include &lt;cstdlib&gt;
9302 #include &lt;iostream&gt;
9303 #include &lt;type_traits&gt;
9304 #include &lt;new&gt;
9305
9306 class A
9307 {
9308     bool alive_;
9309     A(const A&amp;);
9310     A&amp; operator=(const A&amp;);
9311 public:
9312     A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
9313     ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
9314     void use()
9315     {
9316         if (alive_)
9317             std::cout &lt;&lt; "A is alive\n";
9318         else
9319             std::cout &lt;&lt; "A is dead\n";
9320     }
9321 };
9322
9323 void deallocate_resource();
9324
9325 // This is the phoenix singleton pattern
9326 A&amp; get_resource(bool create = true)
9327 {
9328     static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
9329     static A* a;
9330     if (create)
9331     {
9332         if (a != (A*)&amp;buf)
9333         {
9334             a = ::new (&amp;buf) A;
9335             std::atexit(deallocate_resource);
9336         }
9337     }
9338     else
9339     {
9340         a-&gt;~A();
9341         a = (A*)&amp;buf + 1;
9342     }
9343     return *a;
9344 }
9345
9346 void deallocate_resource()
9347 {
9348     get_resource(false);
9349 }
9350
9351 void use_A(const char* message)
9352 {
9353     A&amp; a = get_resource();
9354     std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
9355     a.use();
9356 }
9357
9358 struct B
9359 {
9360     ~B() {use_A("from ~B()");}
9361 };
9362
9363 B b;
9364
9365 int main()
9366 {
9367     use_A("from main()");
9368 }
9369 </pre></blockquote>
9370
9371 <p>
9372 The correct output is:
9373 </p>
9374
9375 <blockquote><pre>A()
9376 Using A from main()
9377 A is alive
9378 ~A()
9379 A()
9380 Using A from ~B()
9381 A is alive
9382 ~A()
9383 </pre></blockquote>
9384
9385 <p><i>[
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.
9390 ]</i></p>
9391
9392
9393
9394
9395 <p><b>Proposed resolution:</b></p>
9396 <p>
9397 </p>
9398
9399
9400
9401
9402
9403 <hr>
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>
9410
9411 <p>
9412 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
9413 member of auto_ptr (20.4.5.3/4) obsolete.
9414 </p>
9415
9416 <p>
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
9419 cv-types) case:
9420 </p>
9421 <pre>#include &lt;memory&gt;
9422 using std::auto_ptr;
9423
9424 struct B {};
9425 struct D : B {};
9426
9427 auto_ptr&lt;D&gt; source();
9428 int sink(auto_ptr&lt;B&gt;);
9429 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
9430 </pre>
9431
9432 <p>
9433 The excellent analysis of conversion operations that was given in the final
9434 auto_ptr proposal
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
9438 auto_ptr designers.
9439 </p>
9440
9441 <p>
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.
9445 </p>
9446
9447 <p>
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
9450 case:</p>
9451 <pre>auto_ptr&lt;D&gt; dp;
9452 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
9453 </pre>
9454
9455 <p>
9456 I'm sure that the original intention was allowing this initialization using
9457 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; 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.
9461 </p>
9462
9463 <p>
9464 Removing the obsolete member will have impact on code that explicitly
9465 invokes it:
9466 </p>
9467 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
9468 </pre>
9469
9470 <p>
9471 IMHO no one ever wrote such awkward code and the reasonable workaround for
9472 #1 is:
9473 </p>
9474 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
9475 </pre>
9476
9477 <p>
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
9481 </p>
9482
9483 <p>
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
9488 no candidates.
9489 </p>
9490
9491 <p>
9492 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
9493 </p>
9494 <pre>int f(auto_ptr&lt;B&gt;, std::string);
9495 auto_ptr&lt;B&gt; source2();
9496
9497 // string constructor throws while auto_ptr_ref
9498 // "holds" the pointer
9499 int x4 = f(source2(), "xyz"); // #4
9500 </pre>
9501
9502 <p>
9503 The theoretic execution sequence that will cause a leak:
9504 </p>
9505 <ol>
9506 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
9507 <li>call string::string(char const*) and throw</li>
9508 </ol>
9509
9510 <p>
9511 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
9512 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
9513 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
9514 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; 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&lt;B&gt;(source())); // warning recursive on all control
9518 paths
9519 </p>
9520
9521 <p>
9522 Dave Abrahams noticed that there is no specification saying that
9523 auto_ptr_ref copy constructor can't throw.
9524 </p>
9525
9526 <p>
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&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
9537 legitimate since the actual argument can't be const yet non const r-value
9538 are acceptable.
9539 </p>
9540
9541 <p>
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.
9547 </p>
9548
9549 <p>The proposed auto_ptr interface:</p>
9550
9551 <pre>namespace std {
9552     template&lt;class X&gt; class auto_ptr {
9553     public:
9554         typedef X element_type;
9555
9556         // 20.4.5.1 construct/copy/destroy:
9557         explicit auto_ptr(X* p=0) throw();
9558         auto_ptr(auto_ptr&amp;) throw();
9559         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
9560         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
9561         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
9562         ~auto_ptr() throw();
9563
9564         // 20.4.5.2 members:
9565         X&amp; operator*() const throw();
9566         X* operator-&gt;() const throw();
9567         X* get() const throw();
9568         X* release() throw();
9569         void reset(X* p=0) throw();
9570
9571     private:
9572         template&lt;class U&gt;
9573         auto_ptr(U&amp; rhs, typename
9574 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
9575     };
9576 }
9577 </pre>
9578
9579 <p>
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
9582 the following:
9583 </p>
9584 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
9585
9586 template&lt;typename T&gt;
9587 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
9588 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
9589 </pre>
9590
9591 <p>
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.
9598 </p>
9599
9600 <p><b>Further changes in standard text:</b></p>
9601 <p>Remove section 20.4.5.3</p>
9602
9603 <p>Change 20.4.5/2 to read something like:
9604 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
9605 ill-formed declaration that will require unspecified diagnostic.</p>
9606
9607 <p>Change 20.4.5.1/4,5,6 to read:</p>
9608
9609 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
9610 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
9611 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
9612 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
9613
9614 <p>Change 20.4.5.1/10</p>
9615 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
9616 </pre>
9617 <p>
9618 10 Requires: Y* can be implicitly converted to X*. The expression delete
9619 get() is well formed.
9620 </p>
9621
9622 <p>LWG TC DR #127 is obsolete.</p>
9623
9624 <p>
9625 Notice that the copy constructor and copy assignment operator should remain
9626 as before and accept non-const auto_ptr&amp; 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:
9629 </p>
9630 <pre>struct X {
9631     // implicit X(X&amp;)
9632     // implicit X&amp; operator=(X&amp;)
9633     auto_ptr&lt;D&gt; aptr_;
9634 };
9635 </pre>
9636
9637 <p>
9638 In most cases this indicates about sloppy programming but preserves the
9639 current auto_ptr behavior.
9640 </p>
9641
9642 <p>
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&lt;Y&gt; 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&lt;X&gt; 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&lt;Y&gt; is
9654 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
9655 from r-value derived to base).
9656 </p>
9657
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>
9661
9662
9663 <p><i>[
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
9666 tool.
9667 ]</i></p>
9668
9669
9670 <p><i>[
9671 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
9672 ]</i></p>
9673
9674
9675 <p><i>[
9676 2009-07 Frankfurt
9677 ]</i></p>
9678
9679
9680 <blockquote>
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.
9683 </blockquote>
9684
9685 <p><i>[
9686 209-10-04 Daniel adds:
9687 ]</i></p>
9688
9689
9690 <blockquote>
9691 <p>
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
9697 </p>
9698
9699 <blockquote><pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp;&amp;) throw();
9700 template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;&amp;&amp;) throw();
9701 </pre></blockquote>
9702
9703 <p>
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.
9711 </p>
9712 </blockquote>
9713
9714 <p><i>[
9715 2009-10 Santa Cruz:
9716 ]</i></p>
9717
9718
9719 <blockquote>
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>.
9722 </blockquote>
9723
9724
9725
9726 <p><b>Proposed resolution:</b></p>
9727 <p>
9728 Change the synopsis in D.12.1 [auto.ptr]:
9729 </p>
9730
9731 <blockquote><pre>namespace std { 
9732   <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
9733
9734   <ins>// exposition only</ins>
9735   <ins>template &lt;class T&gt; struct constant_object;</ins>
9736
9737   <ins>// exposition only</ins>
9738   <ins>template &lt;class T&gt;</ins>
9739   <ins>struct cannot_transfer_ownership_from</ins>
9740     <ins>: constant_object&lt;T&gt; {};</ins>
9741
9742   template &lt;class X&gt; class auto_ptr { 
9743   public: 
9744     typedef X element_type; 
9745
9746     // D.9.1.1 construct/copy/destroy: 
9747     explicit auto_ptr(X* p =0) throw(); 
9748     auto_ptr(auto_ptr&amp;) throw(); 
9749     template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw(); 
9750     auto_ptr&amp; operator=(auto_ptr&amp;) throw(); 
9751     template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
9752     <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
9753     ~auto_ptr() throw(); 
9754
9755     // D.9.1.2 members: 
9756     X&amp; operator*() const throw();
9757     X* operator-&gt;() const throw();
9758     X* get() const throw();
9759     X* release() throw();
9760     void reset(X* p =0) throw();
9761
9762     <del>// D.9.1.3 conversions:</del>
9763     <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
9764     <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
9765     <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
9766
9767     <ins>// exposition only</ins>
9768     <ins>template&lt;class U&gt;</ins>
9769     <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
9770   }; 
9771
9772   template &lt;&gt; class auto_ptr&lt;void&gt; 
9773   { 
9774   public: 
9775     typedef void element_type; 
9776   }; 
9777
9778 }
9779 </pre></blockquote>
9780
9781 <p>
9782 Remove D.12.1.3 [auto.ptr.conv].
9783 </p>
9784
9785 <p>
9786 Change D.12.1 [auto.ptr], p3:
9787 </p>
9788
9789 <blockquote>
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&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</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>]
9807 </blockquote>
9808
9809 <p>
9810 Change D.12.1.1 [auto.ptr.cons], p5:
9811 </p>
9812
9813 <blockquote>
9814 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
9815 </pre>
9816 <blockquote>
9817 <p>
9818 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
9819 </p>
9820 <p>
9821 <i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
9822 </p>
9823 <p>
9824 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
9825 </p>
9826 </blockquote>
9827 </blockquote>
9828
9829 <p>
9830 Change D.12.1.1 [auto.ptr.cons], p10:
9831 </p>
9832
9833 <blockquote>
9834 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
9835 </pre>
9836 <blockquote>
9837 <p>
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.
9840 </p>
9841 <p>
9842 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
9843 </p>
9844 <p>
9845 <i>Returns:</i> <tt>*this</tt>.
9846 </p>
9847 </blockquote>
9848 </blockquote>
9849
9850
9851
9852
9853
9854
9855 <hr>
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>
9862 <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:
9865 </p>
9866
9867 <pre>  #include &lt;string&gt;
9868   int main() { std::string( 0 ); }
9869 </pre>
9870
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>
9874
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>
9880
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>
9888
9889
9890 <p><i>[
9891 Post Summit: Alisdair requests this be re-opened as several new language facilities are
9892 designed to solve exactly this kind of problem.
9893 ]</i></p>
9894
9895
9896 <p><i>[
9897 Batavia (2009-05):
9898 ]</i></p>
9899
9900 <blockquote>
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.
9903 It is also possible
9904 that when <tt>string</tt> is brought into the concepts world,
9905 this issue might be addressed in that context.
9906 </blockquote>
9907
9908 <p><i>[
9909 2009-07 Frankfurt
9910 ]</i></p>
9911
9912
9913 <blockquote>
9914 <p>
9915 We considered three options:
9916 </p>
9917
9918 <ul>
9919 <li>The proposed resolution.</li>
9920 <li>NAD</li>
9921 <li>Interpret a null pointer as the empty string.</li>
9922 </ul>
9923
9924 <p>
9925 The consensus was NAD.
9926 </p>
9927 </blockquote>
9928
9929
9930
9931 <p><b>Proposed resolution:</b></p>
9932 <p>
9933 Add to the synopsis in 21.4 [basic.string]
9934 </p>
9935
9936 <blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins>
9937 </pre></blockquote>
9938
9939
9940
9941
9942
9943 <hr>
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>
9950
9951 <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.
9959 </p>
9960
9961 <p>Read email thread starting with c++std-lib-13637 for more.</p>
9962
9963
9964
9965 <p><b>Proposed resolution:</b></p>
9966
9967 <p>Add to Container Requirements the following new paragraph:</p>
9968
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.
9975 </pre>
9976
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>
9980
9981   
9982
9983
9984 <p><b>Rationale:</b></p>
9985 <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
9989 corner cases.
9990 </p>
9991
9992
9993
9994
9995
9996 <hr>
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>
10004 <p>
10005 There is no "Returns:" clause for std::equal_range, which returns non-void.
10006 </p>
10007
10008
10009 <p><b>Proposed resolution:</b></p>
10010
10011
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>
10014
10015
10016
10017
10018
10019
10020 <hr>
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>
10027
10028 <p>24.1/3 says:</p>
10029 <blockquote><p>
10030   Forward iterators satisfy all the requirements of the input and
10031   output iterators and can be used whenever either kind is specified
10032 </p></blockquote>
10033
10034 <p>
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.
10040 </p>
10041
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>
10043
10044
10045
10046 <p><b>Proposed resolution:</b></p>
10047
10048
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
10054 overhaul.)</p> 
10055
10056
10057
10058
10059
10060 <hr>
10061 <h3><a name="477"></a>477. Operator-&gt; 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>
10068 <p>
10069 The Forward Iterator requirements table contains the following:
10070 </p>
10071 <pre> expression  return type         operational  precondition
10072                                   semantics
10073   ==========  ==================  ===========  ==========================
10074   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
10075               otherwise const U&amp;
10076
10077   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
10078 </pre>
10079
10080 <p>
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:
10084 </p>
10085
10086 <blockquote><p>
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&amp;, t denotes a value of
10090    value type T, o denotes a value of some type that is writable to
10091    the output iterator.
10092 </p></blockquote>
10093
10094 <p>AFAICT if we need the second line at all, it should read the same
10095 as the first line.</p>
10096
10097 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
10098
10099
10100 <p><b>Proposed resolution:</b></p>
10101
10102
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>.
10107 </p>
10108
10109
10110
10111
10112
10113 <hr>
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>
10122
10123 <pre>  struct C {
10124     void* operator new( size_t s ) { return ::operator new( s ); }
10125     // NOTE: this hides in-place and nothrow new
10126   };
10127
10128   int main() {
10129     vector&lt;C&gt; v;
10130     v.push_back( C() );
10131   }
10132 </pre>
10133
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>
10137
10138 <p><i>[
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.
10148 ]</i></p>
10149
10150
10151
10152
10153 <p><b>Proposed resolution:</b></p>
10154
10155
10156
10157
10158
10159
10160
10161 <hr>
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&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
10172
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>
10180
10181
10182 <p><b>Proposed resolution:</b></p>
10183 <p>Change Paragraph 20.3.1 of the Standard from</p>
10184 <pre>    template &lt;class Arg, class Result&gt;
10185     struct unary_function {
10186         typedef Arg argument_type;
10187         typedef Result result_type;
10188     };
10189
10190     template &lt;class Arg1, class Arg2, class Result&gt;
10191     struct binary_function {
10192         typedef Arg1 first_argument_type;
10193         typedef Arg2 second_argument_type;
10194         typedef Result result_type;
10195     };
10196 </pre>
10197
10198 <p>to</p>
10199 <pre>    template &lt;class Arg, class Result&gt;
10200         struct unary_function {
10201         typedef Arg argument_type;
10202         typedef Result result_type;
10203     protected:
10204         ~unary_function() {}
10205     };
10206
10207     template &lt;class Arg1, class Arg2, class Result&gt;
10208     struct binary_function {
10209         typedef Arg1 first_argument_type;
10210         typedef Arg2 second_argument_type;
10211         typedef Result result_type;
10212     protected:
10213         ~binary_function() {}
10214     };
10215 </pre>
10216
10217
10218 <p><b>Rationale:</b></p>
10219 <p>The LWG doesn't believe the existing definition causes anybody any
10220   concrete harm.</p>
10221
10222
10223
10224
10225
10226 <hr>
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>
10233 <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.
10239 </p>
10240
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>
10246
10247
10248
10249 <p><b>Proposed resolution:</b></p>
10250 <p>
10251 </p>
10252
10253
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>
10258
10259
10260
10261
10262
10263 <hr>
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>
10271
10272 <p>[lib.alg.find] requires T to be EqualityComparable:</p>
10273
10274 <pre>template &lt;class InputIterator, class T&gt;
10275    InputIterator find(InputIterator first, InputIterator last,
10276                       const T&amp; value);
10277 </pre>
10278
10279 <p>
10280 However the condition being tested, as specified in the Effects
10281 clause, is actually *i == value, where i is an InputIterator.
10282 </p>
10283
10284 <p>
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.
10288 </p>
10289
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>
10293
10294
10295 <p><b>Proposed resolution:</b></p>
10296
10297 <p>[lib.alg.find]:</p>
10298 <blockquote><p>
10299    Remove [lib.alg.find]/1.
10300 </p></blockquote>
10301
10302 <p>[lib.alg.count]:</p>
10303 <blockquote><p>
10304    Remove [lib.alg.count]/1.
10305 </p></blockquote>
10306
10307 <p>[lib.alg.search]:</p>
10308 <blockquote><p>
10309    Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
10310 </p></blockquote>
10311
10312 <p>[lib.alg.replace]:</p>
10313
10314 <blockquote>
10315    <p>
10316    Remove [lib.alg.replace]/1.
10317    Replace [lb.alg.replace]/2 with:
10318    </p>
10319
10320        <blockquote><p>
10321        For every iterator i in the range [first, last) for which *i == value
10322        or pred(*i) holds perform *i = new_value.
10323        </p></blockquote>
10324
10325    <p>
10326    Remove the first sentence of /4.
10327    Replace the beginning of /5 with:
10328    </p>
10329
10330        <blockquote><p>
10331        For every iterator i in the range [result, result + (last -
10332        first)), assign to *i either...
10333        </p></blockquote>
10334
10335    <p>(Note the defect here, current text says assign to i, not *i).</p>
10336 </blockquote>
10337
10338 <p>[lib.alg.fill]:</p>
10339
10340 <blockquote>
10341    <p>
10342    Remove "Type T is Assignable (23.1), " from /1.
10343    Replace /2 with:
10344    </p>
10345
10346        <blockquote><p>
10347        For every iterator i in the range [first, last) or [first, first + n),
10348        perform *i = value.
10349        </p></blockquote>
10350 </blockquote>
10351
10352 <p>[lib.alg.remove]:</p>
10353 <blockquote><p>
10354    Remove /1.
10355    Remove the first sentence of /6.
10356 </p></blockquote>
10357
10358
10359
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>
10362
10363
10364
10365
10366
10367
10368 <hr>
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>
10376
10377 <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.
10380 </p>
10381
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>
10385
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>
10393
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>
10397
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 &amp;&amp; *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
10406   as expected.</p>
10407
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
10410   to T".</p>
10411
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>
10416
10417
10418 <p><i>[
10419 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
10420 ]</i></p>
10421
10422
10423 <p><i>[
10424 2009-10 Santa Cruz:
10425 ]</i></p>
10426
10427
10428 <blockquote>
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
10431 the future.
10432 </blockquote>
10433
10434
10435
10436 <p><b>Proposed resolution:</b></p>
10437
10438
10439 <p><b>Rationale:</b></p>
10440 <p><i>[
10441 San Francisco:
10442 ]</i></p>
10443
10444
10445 <blockquote>
10446 Solved by
10447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
10448 </blockquote>
10449
10450
10451
10452
10453
10454
10455
10456 <hr>
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>
10463 <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>
10468
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>
10471
10472 <p>a) That each value of the output iterator is written to:
10473 The standard allows:
10474 ++x; ++x; ++x;
10475 </p>
10476
10477 <p>
10478 b) That assignments to the output iterator are made in order
10479 X a(x); ++a; *a=1; *x=2; is allowed
10480 </p>
10481
10482 <p>
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.
10486 </p>
10487
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
10491   redesign.]</i></p>
10492
10493
10494 <p><i>[
10495 2009-07 Frankfurt
10496 ]</i></p>
10497
10498
10499 <blockquote>
10500 Bill provided wording according to consensus.
10501 </blockquote>
10502
10503 <p><i>[
10504 2009-07-21 Alisdair requests change from Review to Open.  See thread starting
10505 with c++std-lib-24459 for discussion.
10506 ]</i></p>
10507
10508
10509 <p><i>[
10510 2009-10 Santa Cruz:
10511 ]</i></p>
10512
10513
10514 <blockquote>
10515 Modified wording.  Set to Review.
10516 </blockquote>
10517
10518 <p><i>[
10519 2009-10 Santa Cruz:
10520 ]</i></p>
10521
10522
10523 <blockquote>
10524 Move to Ready after looking at again in a larger group in Santa Cruz.
10525 </blockquote>
10526
10527 <p><i>[
10528 2010 Pittsburgh:
10529 ]</i></p>
10530
10531
10532 <blockquote>
10533 Moved to NAD Editorial.  Rationale added below.
10534 </blockquote>
10535
10536
10537
10538 <p><b>Rationale:</b></p>
10539 <p>
10540 Solved by N3066.
10541 </p>
10542
10543
10544 <p><b>Proposed resolution:</b></p>
10545 <p>
10546 Change Table 101 \97 Output iterator requirements in 24.2.4 [output.iterators]:
10547 </p>
10548 <blockquote>
10549 <table border="1">
10550 <caption>Table 101 \97 Output iterator requirements</caption>
10551 <tbody><tr>
10552 <th>Expression</th>
10553 <th>Return type</th>
10554 <th>Operational semantics</th>
10555 <th>Assertion/note pre-/post-condition</th>
10556 </tr>
10557
10558 <tr>
10559 <td>
10560 <tt>X(a)</tt>
10561 </td>
10562 <td>
10563 &nbsp;
10564 </td>
10565 <td>
10566 &nbsp;
10567 </td>
10568 <td>
10569 <tt>a = t</tt> is equivalent to <tt>X(a) = t</tt>. note: a destructor is assumed.
10570 </td>
10571 </tr>
10572
10573 <tr>
10574 <td>
10575 <tt>X u(a);</tt><br>
10576 <tt>X u = a;</tt>
10577 </td>
10578 <td>
10579 &nbsp;
10580 </td>
10581 <td>
10582 &nbsp;
10583 </td>
10584 <td>
10585 &nbsp;
10586 </td>
10587 </tr>
10588
10589 <tr>
10590 <td>
10591 <tt>*r = o</tt>
10592 </td>
10593 <td>
10594 result is not used
10595 </td>
10596 <td>
10597 &nbsp;
10598 </td>
10599 <td>
10600 <ins>
10601 Post: <tt>r</tt> is not required to be dereferenceable.  <tt>r</tt> is incrementable.
10602 </ins>
10603 </td>
10604 </tr>
10605
10606 <tr>
10607 <td>
10608 <tt>++r</tt>
10609 </td>
10610 <td>
10611 <tt>X&amp;</tt>
10612 </td>
10613 <td>
10614 &nbsp;
10615 </td>
10616 <td>
10617 <tt>&amp;r == &amp;++r</tt>
10618 <ins>
10619 Post: <tt>r</tt> is dereferenceable, unless otherwise specified.  <tt>r</tt> is not required to be incrementable.
10620 </ins>
10621 </td>
10622 </tr>
10623
10624 <tr>
10625 <td>
10626 <tt>r++</tt>
10627 </td>
10628 <td>
10629 convertible to <tt>const X&amp;</tt>
10630 </td>
10631 <td>
10632 <tt>{X tmp = r;<br>++r;<br>return tmp;}</tt>
10633 </td>
10634 <td>
10635 <ins>
10636 Post: <tt>r</tt> is dereferenceable, unless otherwise specified. <tt>r</tt> is not required to be incrementable.
10637 </ins>
10638 </td>
10639 </tr>
10640
10641 <tr>
10642 <td>
10643 <tt>*r++ = o;</tt>
10644 </td>
10645 <td>
10646 result is not used
10647 </td>
10648 <td>
10649 &nbsp;
10650 </td>
10651 <td>
10652
10653 </td>
10654 </tr>
10655
10656 </tbody></table>
10657 </blockquote>
10658
10659
10660
10661
10662
10663 <hr>
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
10672 copy T.</p>
10673
10674
10675 <p><b>Proposed resolution:</b></p>
10676 <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
10677
10678
10679 <p><b>Rationale:</b></p>
10680
10681
10682
10683
10684
10685
10686 <hr>
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>
10693 <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:
10703 </p>
10704 <pre>    template&lt;typename T&gt;
10705     struct allocator{
10706       template&lt;typename T1&gt;
10707       void construct(pointer T1 const&amp; rt1);
10708     };
10709 </pre>
10710
10711 <p>
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?
10714 </p>
10715
10716
10717 <p><b>Proposed resolution:</b></p>
10718
10719
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>
10725
10726
10727
10728
10729
10730 <hr>
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].
10742 </p>
10743
10744
10745
10746 <p>1) Analysis of current wording:</p>
10747
10748
10749 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
10750
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>
10755
10756 <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).
10764 </p>
10765
10766 <p>
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.
10772 </p>
10773
10774
10775 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
10776
10777 <p>
10778 Current wording says:
10779 "Returns: The end of the resulting range."
10780 </p>
10781
10782 <p>
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.
10787 </p>
10788
10789
10790 <p>
10791 25.2.7 [lib.alg.remove], paragraph 4:
10792 </p>
10793
10794 <p>
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"
10798 </p>
10799
10800 <p>
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.
10804 </p>
10805
10806
10807 <p>2) Description of intended behavior:</p>
10808
10809 <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.
10822 </p>
10823
10824 <p>
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.
10832 </p>
10833
10834
10835
10836 <p>3) Proposed fixes:</p>
10837
10838
10839 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
10840
10841 <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."
10848 </p>
10849
10850 <p>Comments to the new wording:</p>
10851
10852 <p>
10853 a) "Places" has no special meaning, and the everyday language meaning
10854 should fit.
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,
10860 last).
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
10880 algorithm.
10881 </p>
10882
10883 <p>
10884 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
10885
10886 "Returns: The iterator k."
10887 </p>
10888
10889 <p>
10890 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
10891
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
10895 the algorithm."
10896 </p>
10897
10898 <p>
10899 Comments to the new wording:
10900 </p>
10901
10902 <p>
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.
10907 </p>
10908
10909 <p>
10910 [1]:
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.
10915 </p>
10916
10917
10918 <p><b>Proposed resolution:</b></p>
10919
10920
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>
10924
10925
10926
10927
10928
10929 <hr>
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++
10940 community [1].</p>
10941
10942
10943
10944 <p>1) Analysis of current wording:</p>
10945
10946
10947 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
10948
10949 <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"
10955 </p>
10956
10957 <p>
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
10967 [first, last) [2].
10968 </p>
10969
10970 <p>
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
10975 expressions].
10976 </p>
10977
10978
10979 <p>
10980 25.2.8 [lib.alg.unique], paragraph 2:
10981 </p>
10982 <p>Current wording says:
10983 "Returns: The end of the resulting range."</p>
10984
10985 <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.
10991 </p>
10992
10993 <p>2) Description of intended behavior:</p>
10994
10995 <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.
11017 </p>
11018
11019 <p>
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.
11028 </p>
11029
11030
11031
11032 <p>3) Proposed fixes:</p>
11033
11034 <p>
11035 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
11036 </p>
11037
11038 <p>
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
11045 ForwardIterator."
11046 </p>
11047
11048 <p>Comments to the new wording:</p>
11049
11050 <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
11053 additional review.
11054 b) "Places" has no special meaning, and the everyday language meaning
11055 should fit.
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,
11066 last).
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],
11071 paragraph 2.
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
11081 "Postcondition:".
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."
11089 </p>
11090
11091 <p>
11092 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
11093 "Returns: The iterator k."
11094 </p>
11095
11096 <p>
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):
11102 </p>
11103
11104 <p>
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."
11109 </p>
11110
11111 <p>Comments to the new wording:</p>
11112
11113 <p>
11114 a) It is assumed by the author that the algorithm was intended to be
11115 stable.
11116 In case this was not the intent, this paragraph becomes certainly
11117 obsolete.
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.
11122 </p>
11123
11124 <p>
11125 25.2.8 [lib.alg.unique], paragraph 3:
11126 </p>
11127 <p>See DR 239.</p>
11128
11129 <p>
11130 4) References to other DRs:
11131 </p>
11132
11133 <p>
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].
11136 See DR 239.
11137 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
11138 expressions.
11139 </p>
11140
11141 <p>
11142 [1]:
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.
11147 </p>
11148
11149 <p>
11150 [2]:
11151 Illustration of conforming implementations according to current wording:
11152 </p>
11153
11154 <p>
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".
11159 </p>
11160
11161 <p>
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.
11165 </p>
11166
11167
11168 <p><b>Proposed resolution:</b></p>
11169
11170
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>
11175
11176
11177
11178
11179
11180 <hr>
11181 <h3><a name="491"></a>491. std::list&lt;&gt;::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&lt;T, Allocator&gt;::unique operation. However, the
11189 current wording is defective for various reasons.</p>
11190
11191
11192
11193 <p>
11194 1) Analysis of current wording:
11195 </p>
11196
11197 <p>23.3.4.4 [list.ops], paragraph 19:</p>
11198
11199 <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>
11206
11207 <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>
11212
11213 <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>
11216
11217 <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>
11222
11223 <p>
11224 The same problems as pointed out in DR 202 (equivalence relation / order
11225 of arguments for pred()) apply to this paragraph.</p>
11226
11227 <p>
11228 23.3.4.4 [list.ops], paragraph 20:
11229 </p>
11230
11231 <p>
11232 Current wording says:
11233 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
11234 pred(*i, *(i - 1))"</p>
11235
11236 <p>
11237 The sentence makes two times use of invalid iterator arithmetic
11238 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
11239 </p>
11240 <p>
11241 [Note: Minor typos: "in" / missing dot at end of sentence.]
11242 </p>
11243
11244 <p>
11245 23.3.4.4 [list.ops], paragraph 21:</p>
11246
11247 <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>
11252
11253 <p>
11254 See DR 315 regarding "(last - first)" not yielding a range.</p>
11255
11256 <p>
11257 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
11258
11259
11260 <p>2) Description of intended behavior:</p>
11261
11262 <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>
11269
11270 <p>
11271 Furthermore, the resolutions of DR 202 are considered regarding
11272 equivalence relation and order of arguments for a call to pred.</p>
11273
11274 <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>
11279
11280 <p>
11281 3) Proposed fixes:</p>
11282
11283 <p>
11284 Change 23.3.4.4 [list.ops], paragraph 19 to:</p>
11285
11286 <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>
11292
11293 <p>
11294 Comments to the new wording:</p>
11295
11296 <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
11304 15.].
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
11310 for clarity.
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>
11321
11322 <p>
11323 Change 23.3.4.4 [list.ops], paragraph 20 to:</p>
11324
11325 <p>
11326 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
11327 pred(*(i-1), *i)."</p>
11328
11329 <p>
11330 Comments to the new wording:</p>
11331
11332 <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
11336 additional review.
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>
11341
11342 <p>
11343 Change 23.3.4.4 [list.ops], paragraph 21 to:</p>
11344
11345 <p>
11346 "Complexity: If empty() == false, exactly size() - 1 applications of the
11347 corresponding predicate, otherwise no applications of the corresponding
11348 predicate."</p>
11349
11350 <p>
11351 Comments to the new wording:</p>
11352
11353 <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".
11356 </p>
11357
11358 <p>
11359 5) References to other DRs:</p>
11360
11361 <p>See DR 202.
11362 See DR 239.
11363 See DR 315.
11364 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
11365 expressions.</p>
11366
11367
11368
11369 <p><b>Proposed resolution:</b></p>
11370
11371
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
11376 harm.</p>
11377
11378
11379
11380
11381
11382 <hr>
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>
11395
11396 <p>1) Examples of current wording:</p>
11397
11398 <p>Current wording outside clause 25:</p>
11399
11400 <p>
11401 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
11402 "(last - first)"
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)"
11408 </p>
11409
11410 <p>
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>
11413
11414 <p>None of these expressions is valid for the corresponding iterator
11415 category.</p>
11416
11417 <p>Current wording in clause 25:</p>
11418
11419 <p>
11420 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
11421 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
11422 (last2-first2))"
11423 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
11424 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
11425 </p>
11426
11427 <p>
11428 However, current wording of 25 [lib.algorithms], paragraph 9 covers
11429 neither of these four cases:</p>
11430
11431 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
11432
11433 <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>
11437 <pre>{X tmp = a;
11438 advance(tmp, n);
11439 return tmp;
11440 }
11441 </pre>
11442 <p>and that of b-a is the same as of return distance(a, b)"</p>
11443
11444 <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.
11456 </p>
11457
11458 <p>2) Description of intended behavior:</p>
11459
11460 <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>
11470
11471 <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>
11475
11476 <p>3) Proposed fixes:</p>
11477
11478
11479 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
11480
11481 <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>
11487 <pre>{X tmp = a;
11488 advance(tmp, n);
11489 return tmp;
11490 }
11491 </pre>
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)".
11497 </p>
11498
11499 <p>Comments to the new wording:</p>
11500
11501 <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
11511 be deserved.
11512 c) DR 225 is not considered in the new wording.
11513 </p>
11514
11515 <p>
11516 Proposed fixes regarding invalid iterator arithmetic expressions outside
11517 clause 25:</p>
11518
11519 <p>
11520 Either
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
11528 clause 25.
11529 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
11530 obsolete.
11531 Alternatively,
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.
11535 Alternatively,
11536 c) Fix each paragraph (both current wording and possible resolutions of
11537 DRs) containing invalid iterator arithmetic expressions separately.
11538 </p>
11539
11540 <p>5) References to other DRs:</p>
11541
11542 <p>
11543 See DR 225.
11544 See DR 237. The resolution could then also read "Linear in last -
11545 first".
11546 </p>
11547
11548 <p><i>[
11549 Bellevue:
11550 ]</i></p>
11551
11552
11553 <blockquote>
11554 Keep open and ask Bill to provide wording.
11555 </blockquote>
11556
11557 <p><i>[
11558 2009-05-09 Alisdair adds:
11559 ]</i></p>
11560
11561
11562 <blockquote>
11563 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>.
11564 </blockquote>
11565
11566 <p><i>[
11567 2009-07 Frankfurt
11568 ]</i></p>
11569
11570
11571 <blockquote>
11572 <p>
11573 Hinnant: this isn't going to change any user's code or any vendor's implementation.
11574 </p>
11575 <p>
11576 No objection to "NAD without prejudice." If anyone proposes a
11577 resolution, the LWG will consider it.
11578 </p>
11579 <p>
11580 Move to NAD.
11581 </p>
11582 </blockquote>
11583
11584
11585
11586 <p><b>Proposed resolution:</b></p>
11587
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>
11592
11593
11594
11595
11596
11597
11598
11599 <hr>
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>
11607
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>
11610
11611 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
11612
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>
11616
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>
11619
11620 <p>2) There are no changes to intended behaviour</p>
11621
11622 <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>
11626
11627
11628
11629 <p><b>Proposed resolution:</b></p>
11630
11631
11632 <p><b>Rationale:</b></p>
11633 <p>This is descriptive text, not normative, and the meaning is clear.</p>
11634
11635
11636
11637
11638
11639 <hr>
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>
11649
11650 <p>It was my understanding that an associative container could be
11651 implemented as a balanced binary tree.</p>
11652
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>
11657
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>
11660
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))
11664 also.</p>
11665
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>
11672
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>
11676
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>
11683
11684
11685
11686 <p><b>Proposed resolution:</b></p>
11687
11688
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
11692   O(log N).</p>
11693
11694
11695
11696
11697
11698 <hr>
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>
11704 <blockquote><p>
11705 17.3.1.1 Summary</p>
11706
11707 <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. 
11712 </p>
11713 <p>
11714 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, 
11715 other paragraphs are normative.
11716 </p></blockquote> 
11717
11718 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
11719
11720 <blockquote><p>
11721 25.3.1.2 stable_sort
11722 </p>
11723 <pre>template&lt;class RandomAccessIterator&gt; 
11724 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 
11725
11726 template&lt;class RandomAccessIterator, class Compare&gt; 
11727 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
11728 </pre>
11729 <p>
11730 1 Effects: Sorts the elements in the range [first, last).
11731 </p>
11732 <p>
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.
11735 </p>
11736 <p>
11737 3 Notes: Stable: the relative order of the equivalent elements is 
11738 preserved. 
11739 </p></blockquote> 
11740
11741 <p>
11742 The Notes para is informative, and nowhere else is stability mentioned above. 
11743 </p>
11744
11745 <p>
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? 
11751 </p>
11752
11753
11754 <p><b>Proposed resolution:</b></p>
11755 <p>
11756 </p>
11757
11758
11759 <p><b>Rationale:</b></p>
11760 <p>
11761 This change has already been made.
11762 </p>
11763
11764
11765
11766
11767
11768 <hr>
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 &#379;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>
11775 <ol>
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>
11779 </ol>
11780 <p>
11781 Contradiction.
11782 </p>
11783
11784
11785 <p><b>Proposed resolution:</b></p>
11786 <p>
11787 </p>
11788
11789
11790
11791
11792
11793 <hr>
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 &lt;anti_spam_email2003@yahoo.com&gt; <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>
11800 <blockquote><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 &lt;, &gt;, &lt;=, &gt;= do not."
11804 </p></blockquote>
11805
11806 <p>
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&lt;T*&gt; 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
11815 incorrect results.
11816 </p>
11817
11818
11819 <p><b>Proposed resolution:</b></p>
11820 <p>
11821 Add a footnote to 20.5.3/8 saying:
11822 </p>
11823
11824 <blockquote><p>
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&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
11838 void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
11839 char*)(cv void*)a, (cv char*)(cv void*)b).
11840 </p></blockquote>
11841
11842 <p>
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&lt;A&gt;(a,b) returns the same value
11845 as comp&lt;B&gt;(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.
11851 </p>
11852
11853
11854
11855 <p><b>Rationale:</b></p>
11856 <p>
11857 less is already required to provide a strict weak ordering which is good enough
11858 to detect overlapping memory situations.
11859 </p>
11860
11861
11862
11863
11864
11865 <hr>
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>
11872 <p>
11873 Motivation:
11874 </p>
11875
11876 <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 
11880 the standard.
11881 </p>
11882
11883 <p><i>[
11884 2009-07 Frankfurt
11885 ]</i></p>
11886
11887
11888 <blockquote>
11889 <p>
11890 No objection to NAD, Fixed.
11891 </p>
11892 <p>
11893 Move to NAD.
11894 </p>
11895 </blockquote>
11896
11897
11898
11899 <p><b>Proposed resolution:</b></p>
11900 <p>
11901 Append the following point to 22.1.1.1.1:
11902 </p>
11903
11904 <p>
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.
11912 </p>
11913
11914 <p><i>[
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,
11917 Bill.
11918 ]</i></p>
11919
11920
11921
11922
11923
11924
11925
11926 <hr>
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>
11933 <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.
11940 </p>
11941
11942 <p>
11943 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
11944 </p>
11945
11946 <p>
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
11949 one.
11950 </p>
11951
11952 <p>
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.
11955 </p>
11956
11957 <p>
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?
11962 </p>
11963
11964 <p>
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.
11970 </p>
11971
11972 <p>
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.
11979 </p>
11980
11981 <p>
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.
11985 </p>
11986
11987 <p>
11988 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
11989 51". Same bad jargon.
11990 </p>
11991
11992 <p>
11993 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
11994 in Table 51". Same bad jargon.
11995 </p>
11996
11997 <p>
11998 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
11999 as num_get/put.
12000 </p>
12001
12002 <p>
12003 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
12004 as num_get/put.
12005 </p>
12006
12007 <p>
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."
12012 </p>
12013
12014 <p>
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?
12018 </p>
12019
12020 <p>
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.
12023 </p>
12024 <p><i>[
12025 Berlin: Bill to provide wording.
12026 ]</i></p>
12027
12028
12029 <p><i>[
12030 2009-07 Frankfurt
12031 ]</i></p>
12032
12033
12034 <blockquote>
12035 <p>
12036 No objection to NAD.
12037 </p>
12038 <p>
12039 Move to NAD.
12040 </p>
12041 </blockquote>
12042
12043
12044
12045 <p><b>Proposed resolution:</b></p>
12046 <p>
12047 </p>
12048
12049
12050
12051
12052
12053 <hr>
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>
12060 <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 ..."
12063 </p>
12064
12065
12066 <p><b>Proposed resolution:</b></p>
12067 <p>
12068 In 5.1.1 [tr.rand.req], Paragraph 2 replace
12069 </p>
12070
12071 <blockquote><p>
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>,
12075 ...
12076 </p></blockquote>
12077
12078 <p>
12079 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
12080 </p>
12081
12082 <blockquote><p>
12083 creates an engine with the initial internal state
12084 determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
12085 </p></blockquote>
12086
12087 <p><i>[
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.
12090 ]</i></p>
12091
12092
12093 <p><i>[
12094 Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
12095 to Ready.
12096 ]</i></p>
12097
12098
12099
12100
12101 <p><b>Rationale:</b></p>
12102 <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
12110 arguments.
12111 </p>
12112
12113
12114 <p><i>[
12115 Portland:  Subsumed by N2111.
12116 ]</i></p>
12117
12118
12119
12120
12121
12122 <hr>
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>
12129 <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.
12136 </p>
12137
12138
12139 <p><b>Proposed resolution:</b></p>
12140 <p>
12141 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
12142 </p>
12143 <p>
12144 Consequence 2: Add max() and min() functions to those distributions that
12145 do not already have them.
12146 </p>
12147
12148 <p><i>[
12149 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
12150 Marc supports having min and max to satisfy generic programming interface.
12151 ]</i></p>
12152
12153
12154
12155
12156 <p><b>Rationale:</b></p>
12157 <p>Berlin:  N1932 makes this moot: variate_generator has been eliminated.</p>
12158
12159
12160
12161
12162
12163 <hr>
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>
12170 <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
12174 in this way.
12175 </p>
12176
12177
12178 <p><b>Proposed resolution:</b></p>
12179 <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:
12183 </p>
12184 <blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
12185 class uniform_int
12186 {
12187 public:
12188   // types
12189   typedef  UIntType  input_type;
12190   typedef  IntType   result_type;
12191 </pre></blockquote>
12192
12193 <p><i>[
12194 Berlin: Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
12195 eliminated.
12196 ]</i></p>
12197
12198
12199
12200
12201
12202
12203
12204 <hr>
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>
12210 <p>
12211 In [tr.rand.dist.bern] the distribution currently requires;
12212 </p>
12213 <blockquote><pre>typedef  int  input_type;
12214 </pre></blockquote>
12215
12216
12217 <p><b>Proposed resolution:</b></p>
12218 <p>
12219 We believe this is an unfortunate choice, and recommend instead:
12220 </p>
12221 <blockquote><pre>typedef  unsigned int  input_type;
12222 </pre></blockquote>
12223
12224 <p><i>[
12225 Berlin:  Moved to NAD. N1932 makes this moot: the input_type template parameter has been
12226 eliminated.
12227 ]</i></p>
12228
12229
12230
12231
12232
12233
12234
12235 <hr>
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>
12242 <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:
12247 </p>
12248 <blockquote><pre>typedef  RealType  input_type;
12249 </pre></blockquote>
12250 <p>
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. 
12257 </p>
12258 <p>
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.
12263 </p>
12264 <p>
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.
12271 </p>
12272 <p>
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.
12278 </p>
12279 <p>
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,
12283 as appropriate).
12284 </p>
12285 <p>
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.
12290 </p>
12291 <p>
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.
12299 </p>
12300 <p>
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.
12308 </p>
12309
12310
12311 <p><b>Proposed resolution:</b></p>
12312 <blockquote><pre>typedef  RealType  input_type;
12313 </pre></blockquote>
12314
12315 <p><i>[
12316 Berlin:  Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
12317 eliminated.
12318 ]</i></p>
12319
12320
12321
12322
12323
12324
12325 <hr>
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>
12332 <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:
12337 </p>
12338 <blockquote><p>
12339 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
12340 </p></blockquote>
12341 <p>
12342 and so forth. 
12343 </p>
12344 <p>
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.
12350 </p>
12351 <p>
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."
12356 </p>
12357
12358
12359 <p><b>Proposed resolution:</b></p>
12360 <p>
12361 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
12362 void seed(unsigned long value = 19780503) by
12363 </p>
12364
12365 <blockquote><p>
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>
12372
12373 <blockquote><pre><ins>
12374 linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
12375 seed(lcg);
12376 </ins></pre></blockquote>
12377
12378 <p>
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>
12383 </blockquote>
12384
12385 <p><i>[
12386 Jens provided revised wording post Mont Tremblant.
12387 ]</i></p>
12388
12389
12390 <p><i>[
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.
12394 ]</i></p>
12395
12396
12397
12398
12399 <p><b>Rationale:</b></p>
12400 <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&amp;).
12404 </p>
12405
12406 <p><i>[
12407 Portland:  Subsumed by N2111.
12408 ]</i></p>
12409
12410
12411
12412
12413
12414
12415 <hr>
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>
12422 <p>
12423 Paragraph 3 begins:
12424 </p>
12425 <blockquote><p>
12426 The size of the state is r.
12427 </p></blockquote>
12428 <p>
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:
12432 </p>
12433 <blockquote><p>
12434 The size of the state is nr+1.
12435 </p></blockquote>
12436 <p>
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:
12440 </p>
12441 <blockquote><p>
12442 With n=..., the size of the state is nr+1.
12443 </p></blockquote>
12444 <blockquote><p>
12445 The size of the state is nr+1, where n=... .
12446 </p></blockquote>
12447
12448
12449
12450 <p><b>Proposed resolution:</b></p>
12451 <p><i>[
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.
12455 ]</i></p>
12456
12457
12458 <p><i>[
12459 Berlin: N1932 adopts the proposed NAD.
12460 ]</i></p>
12461
12462
12463
12464
12465
12466
12467
12468 <hr>
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>
12474 <p>
12475 Paragraph 2 begins:
12476 </p>
12477 <blockquote><p>
12478 The size of the state is r.
12479 </p></blockquote>
12480 <p>
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,
12484 rather than r.
12485 </p>
12486
12487
12488 <p><b>Proposed resolution:</b></p>
12489 <p>
12490 We recommend the sentence be corrected to match:
12491 </p>
12492 <blockquote><p>
12493  The size of the state is r+1.
12494 </p></blockquote>
12495
12496 <p><i>[
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.
12500 ]</i></p>
12501
12502
12503 <p><i>[
12504 Berlin: N1932 adopts the proposed NAD.
12505 ]</i></p>
12506
12507
12508
12509
12510
12511
12512
12513 <hr>
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>
12520 <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:
12524 </p>
12525 <blockquote><pre>template&lt; class PSRE &gt;
12526 class engine_traits;
12527 </pre></blockquote>
12528 <p>
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&lt;&gt;, 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.
12535 </p>
12536 <p>
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:
12540 </p>
12541 <blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
12542 void crypto( Eng&amp; e, InIter in, OutIter out );
12543 </pre></blockquote>
12544 <p>
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.
12547 </p>
12548 <p>
12549 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
12550 template as: 
12551 </p>
12552 <blockquote><pre>template&lt; class PSRE &gt;
12553 class engine_traits
12554 {
12555   static  std::size_t  bits_of_randomness = 0u;
12556   static  std::string  name()  { return "unknown_engine"; }
12557   // TODO: other traits here
12558 };
12559 </pre></blockquote>
12560 <p>
12561 Further, each engine described in [tr.rand.engine] would be accompanied by a
12562 complete specialization of this new engine_traits template.
12563 </p>
12564
12565
12566
12567 <p><b>Proposed resolution:</b></p>
12568 <p><i>[
12569 Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
12570 feature.  Recommend close as NAD.
12571 ]</i></p>
12572
12573
12574
12575 <p><b>Rationale:</b></p>
12576 <p>
12577 Recommend NAD,
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.
12581 </p>
12582
12583
12584
12585
12586
12587 <hr>
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>
12594 <p>
12595 Paragraph 6 says:
12596 </p>
12597 <blockquote><p>
12598 ... obtained by successive invocations of g, ... 
12599 </p></blockquote>
12600 <p>
12601 We recommend instead:
12602 </p>
12603 <blockquote><p>
12604 ... obtained by taking successive invocations of g mod 2**32, ...
12605 </p></blockquote>
12606 <p>
12607 as the context seems to require only 32-bit quantities be used here.
12608 </p>
12609
12610
12611 <p><b>Proposed resolution:</b></p>
12612 <p>
12613 Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
12614 </p>
12615
12616 <p><i>[
12617 Portland:  Subsumed by N2111.
12618 ]</i></p>
12619
12620
12621
12622
12623
12624
12625 <hr>
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>
12632 <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.
12636 </p>
12637 <p>
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.
12641 </p>
12642 <p>
12643 </p>
12644
12645
12646 <p><b>Proposed resolution:</b></p>
12647 <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."
12651 </p>
12652
12653 <p><i>[
12654 Berlin: N1932 considers this NAD. This is a QOI issue.
12655 ]</i></p>
12656
12657
12658
12659
12660
12661
12662
12663 <hr>
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>
12670 <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&lt;&gt; 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.
12679 </p>
12680 <p>
12681 -- Begin original message --
12682 </p>
12683 <p>
12684 The situation of interest is described in the ECMAScript specification
12685 (ECMA-262), section 15.10.2.15:
12686 </p>
12687 <p>
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 `."
12693 </p>
12694 <p>
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).
12699 </p>
12700 <p>
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&lt;&gt;::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."
12712 </p>
12713 <p>
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!
12719 </p>
12720 <p>
12721 -- End original message --
12722 </p>
12723
12724 <p><i>[
12725 John Maddock adds:
12726 ]</i></p>
12727
12728
12729 <p>
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 
12732 TR1.Regex.
12733 </p>
12734 <p>
12735 Given an expression [c1-c2] that is compiled as case insensitive it:
12736 </p>
12737 <p>
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.
12744 </p>
12745 <p>
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.
12749 </p>
12750 <p>
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 
12759 impractical.
12760 </p>
12761 <p>
12762 Finally note that Unicode has:
12763 </p>
12764 <p>
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)).
12772 </p>
12773 <p>
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.
12777 </p>
12778 <p>
12779 Hoping this doesn't make this even more complex that it was already,
12780 </p>
12781
12782 <p><i>[
12783 Portland:  Alisdair: Detect as invalid, throw an exception.
12784 Pete: Possible general problem with case insensitive ranges.
12785 ]</i></p>
12786
12787
12788 <p><i>[
12789 2009-07 Frankfurt
12790 ]</i></p>
12791
12792
12793 <blockquote>
12794 <p>
12795 We agree that this is a problem, but we do not know the answer.
12796 </p>
12797 <p>
12798 We are going to declare this NAD until existing practice leads us in some direction.
12799 </p>
12800 <p>
12801 No objection to NAD Future.
12802 </p>
12803 <p>
12804 Move to NAD Future.
12805 </p>
12806 </blockquote>
12807
12808
12809
12810 <p><b>Proposed resolution:</b></p>
12811
12812
12813
12814
12815
12816 <hr>
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>
12823 <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.
12830 </p>
12831
12832 <p>
12833 1) Parameters taken by const reference can be changed during execution
12834 of the function
12835 </p>
12836
12837 <p>
12838 Examples:
12839 </p>
12840
12841 <p>
12842 Given std::vector&lt;int&gt; v:
12843 </p>
12844 <p>
12845 v.insert(v.begin(), v[2]);
12846 </p>
12847 <p>
12848 v[2] can be changed by moving elements of vector
12849 </p>
12850
12851
12852 <p>
12853 Given std::list&lt;int&gt; l:
12854 </p>
12855 <p>
12856 l.remove(*l.begin());
12857 </p>
12858 <p>
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
12861 cases.
12862 </p>
12863
12864 <p>
12865 2) A range is given which changes during the execution of the function:
12866 Similarly,
12867 </p>
12868
12869 <p>
12870 v.insert(v.begin(), v.begin()+4, v.begin()+6);
12871 </p>
12872
12873 <p>
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
12880 </p>
12881
12882 <p>
12883 Solution:
12884 </p>
12885
12886 <p>
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:
12891 </p>
12892
12893 <p>
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.
12897 </p>
12898
12899 <p>
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.
12903 </p>
12904
12905 <p>
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:
12908 </p>
12909
12910 <p>
12911 Requires: For each non-negative integer n &lt; (last - first), assigning to
12912 *(result + n) must not alter any value in the range [first + n, last).
12913 </p>
12914
12915 <p>
12916 However, this may add excessive complication.
12917 </p>
12918
12919 <p>
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.
12923 </p>
12924
12925 <p>
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.
12928 </p>
12929
12930 <p><i>[
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.
12935 ]</i></p>
12936
12937
12938
12939
12940 <p><b>Proposed resolution:</b></p>
12941
12942
12943 <p><b>Rationale:</b></p>
12944 <p>
12945 Recommend NAD.
12946 </p>
12947 <ul>
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>
12960 </ul>
12961
12962
12963
12964
12965
12966 <hr>
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>
12973 <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:
12977 </p>
12978
12979 <blockquote><p>
12980     "The iterator and const_iterator types are both const types. It is
12981 unspecified whether they are the same type"
12982 </p></blockquote>
12983
12984 <p>
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.
12989 </p>
12990 <p>
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?
12995 </p>
12996
12997
12998
12999 <p><b>Proposed resolution:</b></p>
13000 <p>
13001 Add to 6.3.4.3p2 (and 6.3.4.5p2):
13002 </p>
13003 <p>
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. 
13007 </p>
13008
13009 <p>
13010 Add a new subsection to 17.4.4 [lib.conforming]:
13011 </p>
13012
13013 <blockquote>
13014 <p>
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.
13019 </p>
13020 <p>
13021        [Note: For example, this occurs when a container's iterator
13022        and const_iterator types are the same. -- end note]
13023 </p>
13024 </blockquote>
13025
13026 <p><i>[
13027 Post-Berlin: Beman supplied wording.
13028 ]</i></p>
13029
13030
13031
13032
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.
13037
13038
13039
13040
13041
13042 <hr>
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>
13048 <p>
13049 17.4.3.8/1 says:
13050 </p>
13051
13052 <blockquote><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.
13057 </p></blockquote>
13058
13059 <p>
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:
13070 </p>
13071
13072 <blockquote><pre>  21 Strings library 
13073   21.3.3 basic_string capacity
13074
13075   void resize(size_type n, charT c);
13076
13077   5 Requires: n &lt;= max_size()
13078   6 Throws: length_error if n &gt; max_size().
13079   7 Effects: Alters the length of the string designated by *this as follows:
13080 </pre></blockquote>
13081
13082 <p>
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.
13087 </p>
13088
13089 <p><i>[
13090 Batavia:  Alan and Pete to work.
13091 ]</i></p>
13092
13093
13094 <p><i>[
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.
13099 ]</i></p>
13100
13101
13102
13103 <p><b>Proposed resolution:</b></p>
13104 <p>
13105 1. Change 17.4.3.8/1 to read:
13106 </p>
13107
13108 <blockquote><p>
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>.
13113 </p></blockquote>
13114
13115 <p>
13116 2. Go through and remove redundant Requires: clauses.  Specifics to be
13117    provided by Dave A.
13118 </p>
13119
13120 <p><i>[
13121 Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
13122 ]</i></p>
13123
13124
13125 <p><i>[
13126 Alan provided the survey
13127 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
13128 ]</i></p>
13129
13130
13131
13132
13133
13134
13135
13136 <hr>
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>
13144 <p>
13145 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
13146 defined in terms of std::less rather than operator&lt;, in order to
13147 support comparison of tuples of pointers.  
13148 </p>
13149
13150 <p><i>[
13151 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
13152 ]</i></p>
13153
13154
13155 <p><i>[
13156 2009-10 Santa Cruz:
13157 ]</i></p>
13158
13159
13160 <blockquote>
13161 <p>
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.
13164 </p>
13165 </blockquote>
13166
13167
13168
13169 <p><b>Proposed resolution:</b></p>
13170 <p>
13171 change 6.1.3.5/5 from:
13172 </p>
13173
13174 <blockquote><p>
13175   Returns: The result of a lexicographical comparison between t and
13176   u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
13177   (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; 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 &lt; f returns false.
13180 </p></blockquote>
13181
13182 <p>
13183 to:
13184 </p>
13185
13186 <blockquote>
13187 <p>
13188   Returns: The result of a lexicographical comparison between t and
13189   u. For any two zero-length tuples e and f, e &lt; f returns false.
13190   Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
13191   (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; 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.
13194 </p>
13195 <p>
13196   Where T is the type of x and U is the type of y:
13197 </p>
13198
13199 <p>
13200      if T and U are pointer types and T is convertible to U, returns
13201      less&lt;U&gt;()(x,y)
13202 </p>
13203
13204 <p>
13205      otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
13206 </p>
13207
13208 <p>
13209      otherwise, returns (bool)(x &lt; y)
13210 </p>
13211 </blockquote>
13212
13213 <p><i>[
13214 Berlin: This issue is much bigger than just tuple (pair, containers,
13215 algorithms). Dietmar will survey and work up proposed wording.
13216 ]</i></p>
13217
13218
13219
13220
13221 <p><b>Rationale:</b></p>
13222 <p>
13223 Recommend NAD.  This will be fixed with the next revision of concepts.
13224 </p>
13225
13226 <p><i>[
13227 San Francisco:
13228 ]</i></p>
13229
13230
13231 <blockquote>
13232 Solved by
13233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
13234 </blockquote>
13235
13236
13237
13238
13239
13240 <hr>
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>
13248 <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
13252 sensible
13253 options:
13254 </p>
13255 <ol>
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>
13259 </ol>
13260 <p>
13261 The issue has practical implications, and stdlib vendors have
13262 taken divergent approaches to it: Dinkumware follows 2,
13263 libstdc++ follows 3.
13264 </p>
13265 <p>
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
13268 assign.
13269 </p>
13270
13271 <p><i>[
13272 The following added by Howard and the example code was originally written by
13273 Dietmar.
13274 ]</i></p>
13275
13276 <p>
13277 Valid code below?
13278 </p>
13279
13280 <blockquote><pre>#include &lt;vector&gt; 
13281 #include &lt;iterator&gt; 
13282 #include &lt;iostream&gt; 
13283
13284 struct foo 
13285
13286     explicit foo(int) {} 
13287 }; 
13288
13289 int main() 
13290
13291     std::vector&lt;int&gt; v_int; 
13292     std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end()); 
13293     std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)), 
13294                              std::istream_iterator&lt;int&gt;()); 
13295
13296 </pre></blockquote>
13297 <p><i>[
13298 Berlin: Some support, not universal, for respecting the explicit qualifier.
13299 ]</i></p>
13300
13301
13302
13303
13304 <p><b>Proposed resolution:</b></p>
13305
13306
13307
13308
13309
13310
13311 <hr>
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>
13318 <p>
13319 According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
13320 &lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
13321 or &lt;cwchar&gt;." This is consistent with the C standard.
13322 </p>
13323 <p>
13324 However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
13325 </p>
13326 <p>
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.
13332 </p>
13333
13334
13335 <p><b>Proposed resolution:</b></p>
13336 <p>
13337 I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
13338 number of macros from C.2, p2 and reword the sentence as follows:
13339 </p>
13340 <blockquote><p>
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.
13344 </p></blockquote>
13345
13346 <p><i>[
13347 Portland:  Resolution is considered editorial.  It will be incorporated into the WD.
13348 ]</i></p>
13349
13350
13351
13352
13353
13354
13355
13356 <hr>
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>
13362 <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&lt;&gt; 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.
13372 </p>
13373
13374 <p><i>[
13375 2009-07 Frankfurt
13376 ]</i></p>
13377
13378
13379 <blockquote>
13380 <p>
13381 We are not going to fix TR1.
13382 </p>
13383 <p>
13384 The paper "long long goes to the library" addresses the integration of
13385 long long into the C++0x library.
13386 </p>
13387 <p>
13388 Move to NAD.
13389 </p>
13390 </blockquote>
13391
13392
13393
13394 <p><b>Proposed resolution:</b></p>
13395 <p>
13396 </p>
13397
13398
13399
13400
13401
13402 <hr>
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>
13409 <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?
13419 </p>
13420
13421
13422 <p><b>Proposed resolution:</b></p>
13423
13424
13425 <p><b>Rationale:</b></p>
13426 <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>.
13429 </p>
13430
13431
13432
13433
13434
13435 <hr>
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>
13442 <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.
13453 </p>
13454
13455 <p><i>[
13456 Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
13457 may block?
13458 ]</i></p>
13459
13460
13461 <p>
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.
13465 </p>
13466
13467
13468 <p><b>Proposed resolution:</b></p>
13469 <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).
13472 </p>
13473
13474
13475
13476
13477
13478 <hr>
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>
13485 <p>
13486 Paragraph 1 says that "A binomial distributon random distribution produces
13487 integer values i&gt;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
13489 are. What's n?
13490 </p>
13491
13492
13493 <p><b>Proposed resolution:</b></p>
13494 <p>
13495 Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
13496 </p>
13497
13498 <p><i>[
13499 Portland:  Subsumed by N2111.
13500 ]</i></p>
13501
13502
13503
13504
13505
13506
13507 <hr>
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>
13514 <p>
13515 In the synopsis, some types are identified as optional: int8_t, int16_t,
13516 and so on, consistently with C99, indeed.
13517 </p>
13518 <p>
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.
13521 </p>
13522
13523
13524 <p><b>Proposed resolution:</b></p>
13525 <p>
13526 Change 18.4.1 [cstdint.syn]:
13527 </p>
13528
13529 <blockquote><pre>...
13530 typedef <i>signed integer type</i> intptr_t;    <ins><i>// optional</i></ins>
13531 ...
13532 typedef <i>unsigned integer type</i> uintptr_t;    <ins><i>// optional</i></ins>
13533 ...
13534 </pre></blockquote>
13535
13536
13537
13538 <p><b>Rationale:</b></p>
13539 Recommend NAD and fix as editorial with the proposed resolution.
13540
13541
13542
13543
13544
13545 <hr>
13546 <h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</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>
13552 <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>
13555 (WP status).
13556 </p>
13557
13558 <p>
13559 The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
13560 The part I'm having a little trouble with is:
13561 </p>
13562 <blockquote><pre>static const bool traps = false;
13563 </pre></blockquote>
13564
13565 <p>
13566 Should this not be implementation defined?  Given:
13567 </p>
13568
13569 <blockquote><pre>int main()
13570 {
13571      bool b1 = true;
13572      bool b2 = false;
13573      bool b3 = b1/b2;
13574 }
13575 </pre></blockquote>
13576
13577 <p>
13578 If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
13579 <tt>true</tt>?
13580 </p>
13581
13582
13583 <p><b>Proposed resolution:</b></p>
13584 <p>
13585 Change 18.2.1.5p3:
13586 </p>
13587
13588 <blockquote><p>
13589 -3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
13590 <blockquote><pre>namespace std { 
13591    template &lt;&gt; class numeric_limits&lt;bool&gt; {
13592       ...
13593       static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
13594       ...
13595    };
13596 }
13597 </pre></blockquote>
13598 </blockquote>
13599
13600 <p><i>[
13601 Redmond:  NAD because traps refers to values, not operations.  There is no bool
13602 value that will trap.
13603 ]</i></p>
13604
13605
13606
13607
13608
13609
13610
13611 <hr>
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>
13617 <p>
13618 This one, if nobody noticed it yet, seems really editorial:
13619 s/cstbool/cstdbool/
13620 </p>
13621
13622
13623 <p><b>Proposed resolution:</b></p>
13624 <p>
13625 Change 8.21p1:
13626 </p>
13627 <blockquote><p>
13628 -1- The header behaves as if it defines the additional macro defined in
13629 <tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
13630 </p></blockquote>
13631
13632 <p><i>[
13633 Redmond:  Editorial.
13634 ]</i></p>
13635
13636
13637
13638
13639
13640
13641
13642 <hr>
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>
13649 <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.
13654 </p>
13655 <p>
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).
13662 </p>
13663 <p>
13664 I'm wondering whether we really, really, want div and abs for intmax_t...
13665 </p>
13666
13667
13668
13669 <p><b>Proposed resolution:</b></p>
13670
13671
13672
13673 <p><i>[
13674 Portland: no consensus.
13675 ]</i></p>
13676
13677
13678 <p><b>Rationale:</b></p>
13679 <p><i>[
13680 Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
13681 ]</i></p>
13682
13683 <blockquote><pre>intmax_t imaxabs(intmax_t i);
13684 intmax_t abs(intmax_t i);
13685
13686 imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
13687 imaxdiv_t div(intmax_t numer, intmax_t denom);
13688 </pre></blockquote>
13689
13690 <p><i>[
13691 and in TR1 8.11.2 [tr.c99.cinttypes.def]:
13692 ]</i></p>
13693
13694
13695 <blockquote><p>
13696 The header defines all functions, types, and macros the same as C99
13697 subclause 7.8.
13698 </p></blockquote>
13699
13700 <p><i>[
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:
13703 ]</i></p>
13704
13705
13706 <blockquote><p>
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>]
13710 </p></blockquote>
13711
13712 <p><i>[
13713 Bellevue: NAD Editorial. Pete must add a footnote, as described below.
13714 ]</i></p>
13715
13716
13717 <blockquote>
13718 <p><i>[
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.
13724 ]</i></p>
13725
13726 </blockquote>
13727
13728
13729
13730
13731
13732
13733 <hr>
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>
13740 <blockquote>
13741 <p>
13742   24.1.1 Input iterators [lib.input.iterators]
13743 </p>
13744 <p>
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
13748   shown in Table 73.
13749 </p>
13750 </blockquote>
13751 <p>
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:
13757 </p>
13758
13759
13760 <p><b>Proposed resolution:</b></p>
13761 <p>
13762 Change 24.1.1p1:
13763 </p>
13764 <blockquote><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.
13769 </p></blockquote>
13770
13771 <p><i>[
13772 Portland: Editorial.
13773 ]</i></p>
13774
13775
13776
13777
13778
13779
13780
13781 <hr>
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>
13789 <p>
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.
13793 </p>
13794 <p>
13795 As a result, there exist implementations that work well with such allocators
13796 and implementations that don't.
13797 </p>
13798
13799 <h4>2. The cause of the problem.</h4>
13800 <p>
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.
13805 </p>
13806 <p>
13807 2) Some container operations are obviously underspecified. In particular,
13808 21.3.7.1p2 tells:
13809 </p>
13810 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
13811   basic_string&lt;charT,traits,Allocator&gt; operator+(
13812     const charT* lhs,
13813     const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
13814   );
13815 </pre>
13816 <p>
13817 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
13818 </p>
13819 </blockquote>
13820 <p>
13821 That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
13822 Obviously, the right requirement is:
13823 </p>
13824 <blockquote><p>
13825 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
13826 </p></blockquote>
13827 <p>
13828 It seems like a lot of DRs can be submitted on this "Absent call to
13829 get_allocator()" topic.
13830 </p>
13831
13832 <h4>3. Proposed actions.</h4>
13833 <p>
13834 1) Explicitly state the intent to allow for user-defined allocators without
13835 default constructor in 20.1.5 Allocator requirements.
13836 </p>
13837 <p>
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.
13840 </p>
13841 <h4>4. Code sample.</h4>
13842 <p>
13843 Let's suppose that the following memory pool is available:
13844 </p>
13845 <blockquote><pre>class mem_pool {
13846       // ...
13847       void* allocate(size_t size);
13848       void deallocate(void* ptr, size_t size);
13849 };
13850 </pre></blockquote>
13851 <p>
13852 So the following allocator can be implemented via this pool:
13853 </p>
13854 <blockquote><pre>class stl_allocator {
13855       mem_pool&amp; pool;
13856
13857  public:
13858       explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
13859       stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
13860       template &lt;class U&gt;
13861       stl_allocator(const stl_allocator&lt;U&gt;&amp; sa)  : pool(sa.get_pool()) {}
13862       ~stl_allocator() {}
13863
13864       pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
13865       {
13866        return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
13867       }
13868
13869       void deallocate(pointer p, size_type n)
13870       {
13871        if (n!=0) pool.deallocate(p, n*sizeof(T));
13872       }
13873
13874       // ...
13875 };
13876 </pre></blockquote>
13877 <p>
13878 Then the following code works well on some implementations and doesn't work on
13879 another:
13880 </p>
13881 <blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt; 
13882   tl_string;
13883 mem_pool mp;
13884 tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
13885 printf("(%s)\n", ("def"+s1).c_str());
13886 </pre></blockquote>
13887 <p>
13888 In particular, on some implementations the code can't be compiled without
13889 default stl_allocator() constructor.
13890 </p>
13891 <p>
13892 The obvious way to solve the compile-time problems is to intentionally define
13893 a NULL pointer dereferencing default constructor
13894 </p>
13895 <blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
13896 </pre></blockquote>
13897 <p>
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&amp;) under the current 21.3.7.1p2
13900 wording.
13901 </p>
13902
13903
13904 <p><b>Proposed resolution:</b></p>
13905 <p>
13906 </p>
13907
13908
13909 <p><b>Rationale:</b></p>
13910 <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).
13913 </p>
13914
13915
13916
13917
13918
13919 <hr>
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>
13925 <p>
13926 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
13927 </p>
13928
13929 <p>
13930 Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
13931 </p>
13932
13933 <p><i>[
13934 Batavia (2009-05):
13935 ]</i></p>
13936
13937 <blockquote>
13938 We agree this has been fixed in the Working Draft.
13939 Move to NAD.
13940 </blockquote>
13941
13942
13943 <p><b>Proposed resolution:</b></p>
13944 <p>
13945 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
13946 </p>
13947
13948
13949
13950
13951
13952 <hr>
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>
13960 <p>
13961 Section: 27.4.4.3 [lib.iostate.flags]
13962 </p>
13963 <p>
13964 Paragraph 4 says:
13965 </p>
13966 <blockquote>
13967 <blockquote><pre>void clear(iostate <i>state</i> = goodbit);
13968 </pre></blockquote>
13969 <p>
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>.
13972 </p>
13973 </blockquote>
13974
13975 <p>
13976 The postcondition "rdstate()==state|ios_base::badbit" is parsed as
13977 "(rdstate()==state)|ios_base::badbit", which is probably what the
13978 committee meant.
13979 </p>
13980
13981
13982
13983
13984 <p><b>Rationale:</b></p>
13985
13986
13987
13988
13989
13990
13991 <hr>
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>
13998 <p>
13999 Currently, the Standard Library specifies only a declaration for template class
14000 char_traits&lt;&gt; and requires the implementation provide two explicit
14001 specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. 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.
14004 </p>
14005 <p>
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.
14010 </p>
14011 <p><i>[
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.
14015 ]</i></p>
14016
14017 <p><i>[
14018 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
14019 ]</i></p>
14020
14021
14022 <p><i>[
14023 post Bellevue:
14024 ]</i></p>
14025
14026
14027 <blockquote>
14028 <p>
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.
14034 </p>
14035 <p>
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.
14039 </p>
14040 </blockquote>
14041
14042 <p><i>[
14043 Sophia Antipolis:
14044 ]</i></p>
14045
14046
14047 <blockquote>
14048 Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
14049 </blockquote>
14050
14051
14052 <p><b>Proposed resolution:</b></p>
14053
14054
14055
14056
14057
14058 <hr>
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>
14065 <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
14068 9899:1999?
14069 </p>
14070 <p>
14071 What impact does this have on the library?
14072 </p>
14073
14074
14075 <p><b>Proposed resolution:</b></p>
14076 <p>
14077 In 1.2/1 [intro.refs] of the WP, change:
14078 </p>
14079 <blockquote>
14080 <ul>
14081 <li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
14082 </ul>
14083 </blockquote>
14084
14085
14086
14087 <p><b>Rationale:</b></p>
14088 Recommend NAD, fixed editorially.
14089
14090
14091
14092
14093
14094 <hr>
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>
14101 <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).
14105 </p>
14106
14107
14108 <p><b>Proposed resolution:</b></p>
14109 <p>
14110 Strike the proposed resolution of issue 507.
14111 </p>
14112 <p><i>[
14113 post-Portland:  Walter and Howard recommend NAD.  The proposed resolution of 507 no longer
14114 exists in the current WD.
14115 ]</i></p>
14116
14117
14118
14119 <p><b>Rationale:</b></p>
14120 <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>
14123 is adopted.
14124 </p>
14125
14126
14127
14128
14129
14130 <hr>
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>
14137 <p>
14138 There are two deficiencies related to file sizes:
14139 </p>
14140 <ol>
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>
14144
14145 <li>The std::fpos class does not currently have the ability to
14146       set/get file positions.</li>
14147 </ol>
14148 <p>
14149 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
14150 </p>
14151 <ol type="A">
14152 <li>Defining fpos_t be long long, which is large enough to
14153       represent any file position likely in the foreseeable future.</li>
14154
14155 <li>Adding member functions to class fpos. For example,
14156 <blockquote><pre>fpos_t seekpos() const;
14157 </pre></blockquote>
14158 </li>
14159 </ol>
14160 <p>
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.
14166 </p>
14167
14168 <p><i>[
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
14172 ]</i></p>
14173
14174
14175 <p><i>[
14176 2009-07 Frankfurt
14177 ]</i></p>
14178
14179
14180 <blockquote>
14181 <p>
14182 This is the subject of paper N2926.
14183 </p>
14184 <p>
14185 If we choose to take any action, we will move the paper, so the issue can be closed.
14186 </p>
14187 <p>
14188 Move to NAD.
14189 </p>
14190 </blockquote>
14191
14192
14193
14194 <p><b>Proposed resolution:</b></p>
14195 <p>
14196 </p>
14197
14198
14199
14200
14201
14202 <hr>
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>
14210 <p>
14211 See
14212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
14213 for full discussion.
14214 </p>
14215
14216 <p><i>[
14217 2009-12-11 Paolo opens:
14218 ]</i></p>
14219
14220
14221 <blockquote>
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.
14224 </blockquote>
14225
14226 <p><i>[
14227 2010-02-07 Paolo updates wording.
14228 ]</i></p>
14229
14230
14231 <blockquote>
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>.
14243 </blockquote>
14244
14245 <p><i>[
14246 2010-02-07 Original wording saved here:
14247 ]</i></p>
14248
14249
14250 <blockquote class="note">
14251 <p>
14252 Option 1:
14253 </p>
14254
14255 <p>
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.
14259 </p>
14260
14261 <p>
14262 Option 2:
14263 </p>
14264
14265 <p>
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 
14268 that
14269 </p>
14270
14271 <blockquote><pre>iterator q1=a.erase(q);
14272 </pre></blockquote>
14273
14274 <p>
14275 works as expected, while
14276 </p>
14277
14278 <blockquote><pre>a.erase(q);
14279 </pre></blockquote>
14280
14281 <p>
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 
14287 code.
14288 </p>
14289
14290 </blockquote>
14291
14292 <p><i>[
14293 2010-03-27 Joaquín adds:
14294 ]</i></p>
14295
14296
14297 <blockquote>
14298 <p>
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>.
14303 </p>
14304
14305 <p>
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.
14312 </p>
14313
14314 <p> 
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.
14322 </p>
14323
14324 <p> 
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.
14331 </p>
14332
14333 <p> 
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).
14342 </p>
14343 </blockquote>
14344
14345 <p><i>[
14346 2010 Rapperswil:
14347 ]</i></p>
14348
14349
14350 <blockquote>
14351 <p>
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.
14354 </p>
14355
14356 <p>
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.
14360 </p>
14361 </blockquote>
14362
14363
14364 <p><b>Rationale:</b></p>
14365
14366 <p>
14367 No consensus for a change.
14368 </p>
14369
14370
14371
14372 <p><b>Proposed resolution:</b></p>
14373
14374
14375
14376
14377
14378 <hr>
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>
14387         <p>
14388
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.
14397
14398         </p>
14399         <p>
14400
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.
14408
14409         </p>
14410         <p>
14411
14412 I  propose  that all  containers  be required  to  make  use of  these
14413 functions.
14414
14415         </p>
14416 <p><i>[
14417 Batavia:  We support this resolution.  Martin to provide wording.
14418 ]</i></p>
14419
14420 <p><i>[
14421 pre-Oxford:  Martin provided wording.
14422 ]</i></p>
14423
14424
14425 <p><i>[
14426 2009-04-28 Pablo adds:
14427 ]</i></p>
14428
14429
14430 <blockquote>
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].
14439 </blockquote>
14440
14441 <p><i>[
14442 2009-07 Frankfurt
14443 ]</i></p>
14444
14445
14446 <blockquote>
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.
14450 </blockquote>
14451
14452 <p><i>[
14453 2009-10 Santa Cruz:
14454 ]</i></p>
14455
14456
14457 <blockquote>
14458 NAD Editorial.  Addressed by
14459 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
14460 </blockquote>
14461
14462
14463
14464     <p><b>Proposed resolution:</b></p>
14465        <p>
14466
14467 Specifically, I propose to change 23.2 [container.requirements],
14468 p9 as follows:
14469
14470        </p>
14471            <blockquote>
14472 <p>
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
14476 first parameters.
14477
14478 All other  constructors for  these container types  take a<del>n</del>
14479 <ins>const</ins>  <code>Allocator&amp;</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>.
14482
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>
14492
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
14504 type.</ins>
14505
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>
14512
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>
14518 </p>
14519 <p>
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&lt;U&gt;::other</code>   for  the  appropriate
14523 type <code>U</code>.
14524 </p>
14525            </blockquote>
14526        <p>
14527
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.
14537
14538        </p>
14539
14540
14541 <p><i>[
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>.
14543 ]</i></p>
14544
14545
14546 <p><i>[
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>.
14549 ]</i></p>
14550
14551
14552
14553
14554
14555 <hr>
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>
14562
14563 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a></p>
14564         <p>
14565
14566 The specialized  algorithms [lib.specialized.algorithms] are specified
14567 as having the general effect of invoking the following expression:
14568
14569         </p>
14570             <pre>
14571 new (static_cast&lt;void*&gt;(&amp;*i))
14572     typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
14573
14574             </pre>
14575         <p>
14576
14577 This  expression is  ill-formed  when the  type  of the  subexpression
14578 <code>&amp;*i</code> is some volatile-qualified <code>T</code>.
14579
14580         </p>
14581
14582 <p><i>[
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.
14586 ]</i></p>
14587
14588
14589
14590 <p><i>[
14591 2009-06-17 Pablo adds:
14592 ]</i></p>
14593
14594
14595 <blockquote>
14596
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>
14598 <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.
14607 </p>
14608 <p>
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:
14611 </p>
14612 <blockquote><pre>template &lt;InputIterator InIter, OutputIterator OutIter&gt;
14613 requires ExplicitConvertible&lt;HasDereference&lt;OutIter::reference&gt;::result,
14614                              OutIter::value_type&amp;&gt;
14615       &amp;&amp; Convertible&lt;OutIter::value_type*, void*&gt;
14616       &amp;&amp; ExplicitConvertible&lt;OutIter::value_type, InIter::reference&gt;
14617   OutIter uninitialized_copy(InIter first, InIter last, OutIter result);
14618 </pre>
14619 <blockquote>
14620 <p>
14621 Effects:
14622 </p>
14623 <blockquote><pre>while (first != last) {
14624   typedef OutIter::value_type value_type;
14625   value_type&amp; outRef = static_cast&lt;value_type&amp;&gt;(*result++);
14626   ::new (static_cast&lt;void*&gt;(addressof(outRef))) value_type(*first++);
14627 }
14628 </pre></blockquote>
14629 </blockquote>
14630
14631 </blockquote>
14632
14633 <p>
14634 Notes:
14635 </p>
14636 <ol>
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.
14639 </li>
14640 <li>
14641 If
14642 OutIter returns a proxy type with an overloaded operator&amp;, this
14643 definition probably won't compile.  Lifting this limitation while
14644 allowing value_type to have an overloaded operator&amp; would be hard, but
14645 is probably possible with careful overloading.  I'm not sure it's worth
14646 it.
14647 </li>
14648 <li>
14649 This definition retains the prohibition on the use of volatile types for the result.
14650 </li>
14651 </ol>
14652
14653 </blockquote>
14654
14655 <p><i>[
14656 2009-07 Frankfurt
14657 ]</i></p>
14658
14659
14660 <blockquote>
14661 <p>
14662 We don't deal with volatile in the library.
14663 </p>
14664 <p>
14665 Jim: should we state that explicitly somewhere?
14666 </p>
14667 <p>
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.
14671 </p>
14672 <p>
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.
14675 </p>
14676 <p>
14677 No objection to NAD.
14678 </p>
14679 <p>
14680 Move to NAD.
14681 </p>
14682 </blockquote>
14683
14684     
14685
14686     <p><b>Proposed resolution:</b></p>
14687         <p>
14688
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:
14693
14694         </p>
14695             <pre>
14696 <i>Effects</i>:
14697
14698 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
14699 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
14700
14701 for (; first != last; ++result, ++first)
14702     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
14703         value_type (*first);
14704
14705             </pre>
14706         <p>
14707
14708 change 20.6.4.2, p1 to read
14709
14710         </p>
14711             <pre>
14712 <i>Effects</i>:
14713
14714 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
14715 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
14716
14717 for (; first != last; ++result, ++first)
14718     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
14719         value_type (*x);
14720
14721             </pre>
14722         <p>
14723
14724 and change 20.6.4.3, p1 to read
14725
14726         </p>
14727             <pre>
14728 <i>Effects</i>:
14729
14730 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
14731 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
14732
14733 for (; n--; ++first)
14734     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
14735         value_type (*x);
14736
14737             </pre>
14738         <p>
14739
14740 In   addition,  since   there   is  no   partial  specialization   for
14741 <code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
14742 to parallel such specialization  for &lt;const T*&gt;. Specifically, I
14743 propose to add the following text to the end of 24.3.1, p3:
14744
14745         </p>
14746         <p>
14747
14748 and for pointers to volatile as 
14749
14750         </p>
14751             <pre>
14752 namespace std {
14753 template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
14754 typedef ptrdiff_t difference_type;
14755 typedef T value_type;
14756 typedef volatile T* pointer;
14757 typedef volatile T&amp; reference;
14758 typedef random_access_iterator_tag iterator_category;
14759 };
14760 }
14761
14762             </pre>
14763         <p>
14764
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.
14771
14772         </p>
14773     
14774
14775
14776
14777 <hr>
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>
14784 <p>
14785 There is no div() function for unsigned integer types.
14786 </p>
14787 <p>
14788 There are several possible resolutions.  The simplest one is noted below.  Other
14789 possibilities include a templated solution.
14790 </p>
14791
14792
14793 <p><b>Proposed resolution:</b></p>
14794 <p>
14795 Add to 26.7 [lib.c.math] paragraph 8:
14796 </p>
14797
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>
14802
14803
14804
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.
14810
14811
14812
14813
14814
14815 <hr>
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>
14822 <p>
14823 There is no pow() function for any integral type.
14824 </p>
14825
14826
14827 <p><b>Proposed resolution:</b></p>
14828 <p>
14829 Add something like:
14830 </p>
14831
14832 <blockquote><pre>template&lt; typename T&gt;
14833 T power( T x, int n );
14834 // requires: n &gt;=0
14835 </pre></blockquote>
14836
14837
14838 <p><b>Rationale:</b></p>
14839 Toronto:  We already have double pow(integral, integral) from 26.8 [c.math] p11.
14840
14841
14842
14843
14844
14845 <hr>
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>
14852         <p>
14853
14854 Section  22.2, paragraph 2  requires facet  <code>get()</code> members
14855 that    take    an    <code>ios_base::iostate&amp;</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
14858 parse error.
14859
14860         </p>
14861         <p>
14862
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.
14866
14867         </p>
14868         <p>
14869
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.
14875
14876         </p>
14877         <p>
14878
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>).
14884
14885         </p>
14886         <p>
14887
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
14892 value.
14893
14894         </p>
14895         <p>
14896
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>.
14902
14903         </p>
14904
14905 <p><i>[
14906 2009-07 Frankfurt
14907 ]</i></p>
14908
14909
14910 <blockquote>
14911 Move to NAD.
14912 </blockquote>
14913
14914     
14915
14916     <p><b>Proposed resolution:</b></p>
14917         <p>
14918
14919 We believe the  intent is for all facet member  functions that take an
14920 <code>ios_base::iostate&amp;</code> argument to:
14921
14922         </p>
14923             <ul>
14924                 <li>
14925
14926 ignore the initial value of the <code><i>err</i></code> argument,
14927
14928                 </li>
14929                 <li>
14930
14931 reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
14932 to any further processing,
14933
14934                 </li>
14935                 <li>
14936
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
14940 error, or both.
14941
14942                 </li>
14943             </ul>
14944         <p>
14945
14946 To that effect we propose to change 22.2, p2 as follows:
14947
14948         </p>
14949         <p>
14950
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&amp;</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>
14963
14964         </p>
14965     
14966     
14967 <p><i>[
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
14971 ]</i></p>
14972
14973
14974
14975
14976 <hr>
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>
14982         <p>
14983
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).
14987
14988         </p>
14989     
14990
14991     <p><b>Proposed resolution:</b></p>
14992         <p>
14993
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.
14996
14997         </p>
14998
14999 <p><i>[
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>
15002 ]</i></p>
15003
15004
15005     
15006
15007
15008
15009 <hr>
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>
15016 <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:
15019 </p>
15020 <p>
15021 * "An instance of array&lt;T, N&gt; stores N elements of type T, so that
15022 [...]"
15023 </p>
15024 <p>
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()
15028 and end():
15029 </p>
15030 <p>
15031 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
15032 end() == unique value."
15033 </p>
15034 <p>
15035 What does "unique" mean in this context? Let's consider the following
15036 possible implementations, all relying on a partial specialization:
15037 </p>
15038 <blockquote><pre>a)
15039     template&lt; typename T &gt;
15040     class array&lt; T, 0 &gt; {
15041     
15042         ....
15043
15044         iterator begin()
15045         { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
15046         ....
15047
15048     };
15049 </pre></blockquote>
15050 <p>
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.
15055 </p>
15056 <blockquote><pre>b)
15057     template&lt; typename T &gt;
15058     class array&lt; T, 0 &gt; {
15059     
15060         T t;
15061
15062         iterator begin()
15063         { return iterator( &amp;t ); }
15064         ....
15065
15066     };
15067 </pre></blockquote>
15068 <p>
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.
15072 </p>
15073 <p>
15074 A slight variant could be returning *the* null pointer of type T
15075 </p>
15076 <blockquote><pre>    return static_cast&lt;T*&gt;(0);
15077 </pre></blockquote>
15078 <p>
15079 In this case the value would be unique to the type array&lt;T, 0&gt; but not
15080 to the objects (all objects of type array&lt;T, 0&gt; with the same value
15081 for T would yield the same pointer value).
15082 </p>
15083 <p>
15084 Furthermore this is inconsistent with what the standard requires from
15085 allocation functions (see library issue 9).
15086 </p>
15087 <p>
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.
15090 </p>
15091 <p>
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
15094 could be defined
15095 </p>
15096 <blockquote><pre>    struct holder { holder() {} T t; } h;
15097 </pre></blockquote>
15098 <p>
15099 and then begin be defined as
15100 </p>
15101 <blockquote><pre> iterator begin() { return &amp;h.t; }
15102 </pre></blockquote>
15103 <p>
15104 But then, it's arguable whether the array stores a T or not.
15105 Indirectly it does.
15106 </p>
15107 <p>
15108 -----------------------------------------------------
15109 </p>
15110 <p>
15111 Now, on different issues:
15112 </p>
15113 <p>
15114 * what's the effect of calling assign(T&amp;) 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)
15118 </p>
15119 <p>
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 &lt;array&gt; header defines.
15127 </p>
15128 <p>
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
15131 </p>
15132 <p>
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"
15137 </p>
15138 <p>
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
15142 </p>
15143
15144 <p><i>[
15145 2009-05-29 Daniel adds:
15146 ]</i></p>
15147
15148
15149 <blockquote>
15150 <ol type="a">
15151 <li>
15152 <p>
15153 star bullet 1 ("what's the effect of calling <tt>assign(T&amp;)</tt> on a
15154 zero-sized array?[..]");
15155 </p>
15156 <blockquote>
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.
15160 </blockquote>
15161 </li>
15162 <li>
15163 <p>
15164 star bullet 3 ("it would be desiderable to have a static const data
15165 member..."):
15166 </p>
15167 <blockquote>
15168 It seems that <tt>tuple_size&lt;array&lt;T, N&gt; &gt;::value</tt> as of 23.3.1.8 [array.tuple] does
15169 provide this functionality now.
15170 </blockquote>
15171 </li>
15172 </ol>
15173 </blockquote>
15174
15175 <p><i>[
15176 2009-07 Frankfurt
15177 ]</i></p>
15178
15179
15180 <blockquote>
15181 <p>
15182 Alisdair to address by the next meeting, or declare NAD.
15183 </p>
15184 <p>
15185 Moved to Tentatively NAD.
15186 </p>
15187 </blockquote>
15188
15189 <p><i>[
15190 2009 Santa Cruz:
15191 ]</i></p>
15192
15193
15194 <blockquote>
15195 Moved to NAD.
15196 </blockquote>
15197
15198
15199
15200 <p><b>Proposed resolution:</b></p>
15201 <p>
15202 </p>
15203
15204
15205 <p><i>[
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
15209 ]</i></p>
15210
15211
15212
15213
15214
15215 <hr>
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>
15222 <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:
15225 </p>
15226
15227 <blockquote><p>
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>]
15230 </p></blockquote>
15231
15232 <p>
15233 Note:
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.
15236 </p>
15237
15238
15239
15240 <p><b>Proposed resolution:</b></p>
15241 <p>
15242 Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
15243 </p>
15244
15245 <p><i>[
15246 post-Oxford: Recommend NAD Editorial.  This resolution is now in the
15247 current working draft.
15248 ]</i></p>
15249
15250
15251
15252
15253
15254
15255
15256 <hr>
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>
15263 <p>
15264 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
15265 Paragraph 7:
15266 </p>
15267 <blockquote><p>
15268 "For built-in integer types, the number of non-sign bits in the
15269 representation."
15270 </p></blockquote>
15271
15272 <p>
15273 26.1 Numeric type requirements [lib.numeric.requirements]
15274 Footnote:
15275 </p>
15276
15277 <blockquote><p>
15278 "In other words, value types. These include built-in arithmetic types,
15279 pointers, the library class complex, and instantiations of valarray for
15280 value types."
15281 </p></blockquote>
15282
15283 <p>
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.
15291 </p>
15292
15293
15294 <p><b>Proposed resolution:</b></p>
15295 <p>
15296 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
15297 Paragraph 7:
15298 </p>
15299 <blockquote><p>
15300 "For <del>built-in</del> integer types, the number of non-sign bits in the
15301 representation."
15302 </p></blockquote>
15303
15304 <p>
15305 26.1 Numeric type requirements [lib.numeric.requirements]
15306 Footnote:
15307 </p>
15308
15309 <blockquote><p>
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
15312 value types."
15313 </p></blockquote>
15314
15315
15316 <p><b>Rationale:</b></p>
15317 <p>
15318 Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
15319 </p>
15320
15321
15322
15323
15324
15325 <hr>
15326 <h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;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>
15332 <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:
15336 </p>
15337 <blockquote>
15338 <pre>void close();
15339 </pre>
15340 <p>
15341 Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
15342 </p>
15343 </blockquote>
15344 <p>
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.
15349 </p>
15350
15351
15352 <p><b>Proposed resolution:</b></p>
15353 <p>
15354 Change 27.9.1.9 [ifstream.members], p5:
15355 </p>
15356
15357 <blockquote><p>
15358 <i>Effects:</i> Calls <tt>rdbuf()-&gt;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>
15361 (27.4.4.3)).
15362 </p></blockquote>
15363
15364 <p>
15365 Change 27.9.1.17 [fstream.members], p5:
15366 </p>
15367
15368 <blockquote><p>
15369 <i>Effects:</i> Calls <tt>rdbuf()-&gt;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>
15372 (27.4.4.3)).
15373 </p></blockquote>
15374
15375
15376
15377 <p><i>[
15378 Kona (2007): Proposed Disposition: NAD, Editorial
15379 ]</i></p>
15380
15381
15382
15383
15384
15385 <hr>
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>
15392 <p>
15393 In a private email, Daveed writes:
15394 </p>
15395 <blockquote>
15396 <p>
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.
15401 </p>
15402 <p>
15403 Here is an example:
15404 </p>
15405 </blockquote>
15406 <pre>
15407          struct S {
15408            S(_Decimal32 const&amp;);  // Converting constructor
15409          };
15410          void f(S);
15411
15412          void f(_Decimal64);
15413
15414          void g(_Decimal32 d) {
15415            f(d);
15416          }
15417 </pre>
15418
15419 <blockquote>
15420 <p>
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.
15424 </p>
15425 <p>
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.
15430 </p>
15431 </blockquote>
15432 <p>
15433 Robert comments:
15434 </p>
15435 <p>
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:
15437 </p>
15438 <pre>                 _Decimal32 d1;
15439                  d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
15440 </pre>
15441 <p>
15442 In preparing the decimal TR, we have three options:
15443 </p>
15444 <ol>
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>
15448 </ol>
15449 <p>
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.
15451 </p>
15452 <p>
15453 Note that neither example above implies any problems with respect to C-to-C++ compatibility, since neither example can be expressed in C.
15454 </p>
15455
15456 <p><i>[
15457 2009-07 Frankfurt
15458 ]</i></p>
15459
15460
15461 <blockquote>
15462 <p>
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
15466 explicitly.
15467 </p>
15468 <p>
15469 Move to NAD.
15470 </p>
15471 </blockquote>
15472
15473
15474
15475 <p><b>Proposed resolution:</b></p>
15476
15477
15478
15479
15480
15481 <hr>
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>
15488 <p>
15489 In c++std-lib-17205, Martin writes:
15490 </p>
15491 <blockquote><p>
15492 ...was it a deliberate design choice to make narrowing assignments ill-formed while permitting narrowing compound assignments?  For instance:
15493 </p></blockquote>
15494 <pre>      decimal32 d32;
15495       decimal64 d64;
15496
15497       d32 = 64;     // error
15498       d32 += 64;    // okay
15499 </pre>
15500 <p>
15501 In c++std-lib-17229, Robert responds:
15502 </p>
15503 <blockquote><p>
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.
15505 </p></blockquote>
15506
15507 <p><i>[
15508 2009-07 Frankfurt
15509 ]</i></p>
15510
15511
15512 <blockquote>
15513 <p>
15514 The current state of the Decimal TR is the result of a deliberate design
15515 decision that has been examined many times.
15516 </p>
15517 <p>
15518 Move to NAD.
15519 </p>
15520 </blockquote>
15521
15522
15523 <p><b>Proposed resolution:</b></p>
15524 <p>
15525 1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
15526 </p>
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>);
15530 </pre>
15531 <p>
15532 2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
15533 </p>
15534 <p>
15535 3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
15536 </p>
15537 <pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
15538                 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
15539 </pre>
15540 <p>
15541 4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
15542 </p>
15543
15544 <p><i>[
15545 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
15546 ]</i></p>
15547
15548
15549
15550
15551
15552
15553 <hr>
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>
15560 <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 
15565 object."
15566 </p>
15567 <p>
15568 Section 21.3.2/1 lists two constructors:
15569 </p>
15570 <blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
15571
15572 basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
15573              size_type pos , size_type n = npos,
15574              const Allocator&amp; a = Allocator());
15575 </pre></blockquote>
15576 <p>
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.
15579 </p>
15580 <p><i>[
15581 Batavia:  We need blanket statement to the effect of:
15582 ]</i></p>
15583
15584
15585 <ol>
15586 <li>If an allocator is passed in, use it, or,</li>
15587 <li>If a string is passed in, use its allocator.</li>
15588 </ol>
15589 <p><i>[
15590 Review constructors and functions that return a string; make sure we follow these
15591 rules (substr, operator+, etc.).  Howard to supply wording.
15592 ]</i></p>
15593
15594
15595 <p><i>[
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:
15598
15599 </i></p><blockquote><i>
15600 All other constructors for these container types take an
15601 <tt>Allocator&amp;</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>
15606 ]</i><p></p>
15607
15608
15609 <p><i>[
15610 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
15611 ]</i></p>
15612
15613
15614 <p><i>[
15615 2009-07 Frankfurt
15616 ]</i></p>
15617
15618
15619 <blockquote>
15620 Move to NAD.
15621 </blockquote>
15622
15623
15624
15625 <p><b>Proposed resolution:</b></p>
15626 <p>
15627 </p>
15628
15629
15630
15631
15632
15633 <hr>
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>
15640 <p>
15641 In the current draft N2134, 21.4/1 says
15642 </p>
15643 <p>
15644 "Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;, 
15645 &lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions), 
15646 respectively."
15647 </p>
15648 <p>
15649 Here footnote 229 applies to table 62, not table 63.
15650 </p>
15651 <p>
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 
15654 in table 63.
15655 </p>
15656
15657
15658 <p><b>Proposed resolution:</b></p>
15659 <p>
15660 </p>
15661
15662
15663 <p><b>Rationale:</b></p>
15664 <p>
15665 Recommend NAD, editorial.  Send to Pete.
15666 </p>
15667
15668
15669
15670
15671
15672 <hr>
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>
15679 <p>
15680 The <tt>&lt;array&gt;</tt> header is given under 23.3 [sequences].
15681 23.3.1 [array]/paragraph 3 says:
15682 </p>
15683 <blockquote><p>
15684 "Unless otherwise specified, all array operations are as described in
15685 23.2 [container.requirements]".
15686 </p></blockquote>
15687 <p>
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].
15691 </p>
15692 <p>
15693 Also, Table 83 "Optional sequence operations" lists several operations that 
15694 std::array does have, but array isn't mentioned.
15695 </p>
15696
15697 <p><i>[
15698 2009-07 Frankfurt
15699 ]</i></p>
15700
15701
15702 <blockquote>
15703 <p>
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:
15708 </p>
15709 <ol>
15710 <li>
15711 a sequence container is one that satisfies all sequence container requirements
15712 </li>
15713 <li>
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.
15719 </li>
15720 </ol>
15721 <p>
15722 Move to Tentatively NAD.
15723 </p>
15724 </blockquote>
15725
15726 <p><i>[
15727 2009-07-15 Loïc Joly adds:
15728 ]</i></p>
15729
15730
15731 <blockquote>
15732 <p>
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).
15738 </p>
15739
15740 <p>
15741 Proposed resolution 1 (minimal change): 
15742 </p>
15743 <blockquote>
15744 <p>
15745 Say that array is a container, that in addition follows only some of the
15746 sequence requirements, as described in the array section:
15747 </p>
15748
15749 <blockquote>
15750 The library provides <del>five</del> <ins>three</ins> basic kinds of sequence containers: <del><tt>array</tt></del>,
15751 <tt>vector</tt>, 
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>
15755 </blockquote>
15756
15757 </blockquote>
15758
15759 <p>
15760 Proposed resolution 2 (most descriptive description, no full wording provided): 
15761 </p>
15762 <blockquote>
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).
15768 </blockquote>
15769 </blockquote>
15770
15771 <p><i>[
15772 2009-07 Frankfurt:
15773 ]</i></p>
15774
15775
15776 <blockquote>
15777 Move to NAD Editorial
15778 </blockquote>
15779
15780 <p><i>[
15781 2009 Santa Cruz:
15782 ]</i></p>
15783
15784
15785 <blockquote>
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.
15789 </blockquote>
15790
15791
15792
15793 <p><b>Proposed resolution:</b></p>
15794 <p>
15795 </p>
15796
15797
15798
15799
15800
15801 <hr>
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>
15808         <p>
15809
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).
15816
15817         </p>
15818         <p>
15819
15820 Propose add a bullet for <i>Remarks</i> along with a brief description.
15821
15822         </p>
15823 <p><i>[
15824 Batavia:  Alan and Pete to work.
15825 ]</i></p>
15826
15827
15828 <p><i>[
15829 Bellevue: Already resolved in current working paper.
15830 ]</i></p>
15831
15832
15833
15834 <p><b>Proposed resolution:</b></p>
15835 <p>
15836 </p>
15837
15838
15839
15840
15841
15842 <hr>
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>
15849 <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>.
15859 </p>
15860
15861 <p><i>[
15862 Bellevue: NAD.  1.4p2 specifies a program must behave correctly "within
15863 its resource limits", so no further escape hatch is necessary.
15864 ]</i></p>
15865
15866
15867
15868 <p><b>Proposed resolution:</b></p>
15869 <p>
15870 </p>
15871
15872
15873
15874
15875
15876 <hr>
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>
15883 <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:
15886 </p>
15887
15888 <blockquote><p>
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>.
15897 </p></blockquote>
15898
15899 <p>
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>).
15904 </p>
15905
15906 <p>
15907 In the description of <tt>lexicographical_compare</tt>, we have both
15908 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
15909 &lt; *<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>".
15912 </p>
15913
15914 <p>
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:
15920 </p>
15921
15922 <p>
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.
15930 </p>
15931
15932 <p><i>[
15933 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
15934 and <tt>upper_bound</tt> to work withoutt these changes.
15935 ]</i></p>
15936
15937
15938 <p><i>[
15939 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
15940 ]</i></p>
15941
15942
15943 <p><i>[
15944 2009-10 Santa Cruz:
15945 ]</i></p>
15946
15947
15948 <blockquote>
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
15953 is moot.
15954 </blockquote>
15955
15956 <p><i>[
15957 2010-01-16 Beman clarified wording.
15958 ]</i></p>
15959
15960
15961 <p><i>[
15962 2010-01-31: Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
15963 Rationale added below.
15964 ]</i></p>
15965
15966
15967
15968
15969 <p><b>Rationale:</b></p>
15970 <p><i>[
15971 post San Francisco:
15972 ]</i></p>
15973
15974
15975 <blockquote>
15976 <p>
15977 Solved by
15978 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2759.pdf">N2759</a>.
15979 </p>
15980 </blockquote>
15981
15982 <p>
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.
15986 </p>
15987
15988
15989
15990 <p><b>Proposed resolution:</b></p>
15991 <p><i>Change 25 [algorithms] paragraph 8 as indicated:</i></p>
15992
15993 <blockquote>
15994
15995 <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>
16016 </p>
16017
16018 </blockquote>
16019
16020
16021
16022
16023
16024
16025 <hr>
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>
16032 <p>
16033 A recent news group discussion:
16034 </p>
16035 <blockquote>
16036 <p>
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.
16041 </p>
16042 <p>
16043 That would be pointless. size() is O(1).
16044 </p>
16045 <p>
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&lt;&gt;</tt> as a part of
16048 some trade-off with other operation.
16049 </p>
16050
16051 <p>
16052 I was aware of that, hence my reluctance to use size() for std::set.
16053 </p>
16054 <p>
16055 However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
16056 </p>
16057 <p>
16058 Ok, I guess the only option is to try it and see...
16059 </p>
16060 </blockquote>
16061
16062 <p>
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.
16066 </p>
16067 <p>
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
16070 away.
16071 </p>
16072
16073 <p><i>[
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.
16078 ]</i></p>
16079
16080
16081 <p><i>[
16082 Bellevue:
16083 ]</i></p>
16084
16085
16086 <blockquote>
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).
16090 </blockquote>
16091
16092 <p><i>[
16093 Batavia (2009-05):
16094 ]</i></p>
16095
16096 <blockquote>
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.
16101 </blockquote>
16102
16103 <p><i>[
16104 2009-07 Frankfurt
16105 ]</i></p>
16106
16107
16108 <blockquote>
16109 Fixed by paper N2923.
16110 </blockquote>
16111
16112
16113
16114 <p><b>Proposed resolution:</b></p>
16115 <p>
16116 </p>
16117
16118
16119
16120
16121
16122 <hr>
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>
16128 <p>
16129 20.8.14.2.5 [func.wrap.func.targ], p4 says:
16130 </p>
16131 <blockquote><p>
16132 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
16133 function target; otherwise a null pointer.
16134 </p></blockquote>
16135
16136 <ol>
16137 <li>
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.
16141 </li>
16142 <li>
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.
16146 </li>
16147 </ol>
16148
16149
16150
16151 <p><b>Proposed resolution:</b></p>
16152 <p>
16153 Change 20.8.14.2.5 [func.wrap.func.targ], p4:
16154 </p>
16155
16156 <blockquote><p>
16157 <i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
16158 typeid(void)</ins></tt>, a pointer to the stored function target;
16159 otherwise a null pointer.
16160 </p></blockquote>
16161
16162 <p><i>[
16163 Pete: Agreed. It's editorial, so I'll fix it.
16164 ]</i></p>
16165
16166
16167
16168
16169
16170
16171
16172 <hr>
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>
16179 <p>
16180 The signature of the const operator[] has been changed to return a const 
16181 reference.
16182 </p>
16183 <p>
16184 The description in paragraph 1 still says that the operator returns by 
16185 value.
16186 </p>
16187 <p><i>[
16188 Pete recommends editorial fix.
16189 ]</i></p>
16190
16191
16192
16193 <p><b>Proposed resolution:</b></p>
16194 <p>
16195 </p>
16196
16197
16198
16199
16200
16201 <hr>
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>
16208 <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 
16212 overload.
16213 </p>
16214
16215
16216 <p><b>Proposed resolution:</b></p>
16217 <p>
16218 Change 26.8 [c.math], paragraph 10,
16219 </p>
16220
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);
16226
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>
16233
16234
16235
16236
16237
16238 <hr>
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>
16245 <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>.
16248 </p>
16249
16250 <p>
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
16254 </p>
16255
16256 <blockquote><p>
16257 "[..] Characters are extracted and inserted until
16258 any of the following occurs:
16259 </p>
16260 <p>
16261 [..]
16262 </p>
16263 <p>
16264 - an exception occurs (in which case the exception is caught)."
16265 </p></blockquote>
16266
16267 <p>
16268 and 15
16269 </p>
16270
16271 <blockquote><p>
16272 "If the function inserts no characters, it calls setstate(failbit),
16273 which
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
16277 caught
16278 exception is rethrown."
16279 </p></blockquote>
16280
16281 <p>
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
16284 for
16285 ever. It seems that even if failbit is on in exceptions() rethrow is
16286 not
16287 allowed due to the wording "If it inserted no characters because it
16288 caught an exception thrown while extracting".
16289 </p>
16290
16291 <p>
16292 Is this behaviour by design?
16293 </p>
16294
16295 <p>
16296 I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
16297 (also
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::
16301 </p>
16302 <p>
16303 1) Paragraph 8 says at its end:
16304 </p>
16305
16306 <blockquote><p>
16307 "- an exception occurs while getting a character from sb."
16308 </p></blockquote>
16309
16310 <p>
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.
16313 </p>
16314
16315 <p>
16316 2) Paragraph 9 says:
16317 </p>
16318
16319 <blockquote><p>
16320 "If the function inserts no characters, it calls setstate(failbit)
16321 (which
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
16324 state,
16325 and if failbit is on in exceptions() the caught exception is
16326 rethrown."
16327 </p></blockquote>
16328
16329 <p>
16330 The sentence starting with "If an exception was thrown" seems to
16331 imply that such an exception *should* be caught before.
16332 </p>
16333
16334
16335 <p><b>Proposed resolution:</b></p>
16336 <p>
16337 (a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
16338 </p>
16339
16340 <blockquote><p>
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.
16349 </p></blockquote>
16350
16351 <p>
16352 (b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
16353 </p>
16354
16355 <blockquote>
16356 <p>
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
16359 following occurs:
16360 </p>
16361 <ul>
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>
16366 </ul>
16367 </blockquote>
16368
16369
16370
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.
16377
16378
16379
16380
16381
16382 <hr>
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>
16389 <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:
16392 </p>
16393
16394 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
16395 </pre></blockquote>
16396
16397
16398 <p><b>Proposed resolution:</b></p>
16399 <p>
16400 Change 27.7.4 [ext.manip], p4:
16401 </p>
16402
16403 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
16404 </pre></blockquote>
16405
16406 <p><i>[
16407 Oxford:  Editorial.
16408 ]</i></p>
16409
16410
16411
16412
16413
16414
16415
16416 <hr>
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>
16423 <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>.
16427 </p>
16428
16429 <p>
16430 Now it's properly written as
16431 </p>
16432
16433 <blockquote><p>
16434 "If that function does not return a null pointer calls clear(),
16435 otherwise
16436 calls setstate(failbit)[..]"
16437 </p></blockquote>
16438
16439 <p>
16440 instead of the previous
16441 </p>
16442
16443 <blockquote><p>
16444 "If that function returns a null pointer, calls setstate(failbit)[..]
16445 </p></blockquote>
16446
16447 <p>
16448 While the old footnotes saying
16449 </p>
16450
16451 <blockquote><p>
16452 "A successful open does not change the error state."
16453 </p></blockquote>
16454
16455 <p>
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,
16459 although
16460 they where needed for that time).
16461 </p>
16462
16463
16464 <p><b>Proposed resolution:</b></p>
16465 <p>
16466 In 27.9.1.9 [ifstream.members], remove footnote:
16467 </p>
16468
16469 <blockquote><p>
16470 <del><sup>334)</sup> A successful open does not change the error state.</del>
16471 </p></blockquote>
16472
16473 <p>
16474 In 27.9.1.13 [ofstream.members], remove footnote:
16475 </p>
16476
16477 <blockquote><p>
16478 <del><sup>335)</sup> A successful open does not change the error state.</del>
16479 </p></blockquote>
16480
16481
16482
16483
16484
16485
16486 <hr>
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>
16493 <p>
16494 20.8.14.2 [func.wrap.func]
16495 </p>
16496 <p>
16497 The note in paragraph 2 refers to 'undefined void operators', while the
16498 section declares a pair of operators returning bool.
16499 </p>
16500
16501 <p><i>[
16502 Post-Sophia Antipolis:
16503 ]</i></p>
16504
16505
16506 <blockquote>
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?
16510 </blockquote>
16511
16512 <p><i>[
16513 2009-05-02 Daniel adds:
16514 ]</i></p>
16515
16516
16517 <blockquote>
16518 <p>
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
16521 </p>
16522 <blockquote><pre>template &lt;class Y&gt; bool operator&lt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;
16523 template &lt;class Y&gt; bool operator&lt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;
16524 template &lt;class Y&gt; bool operator&gt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;
16525 template &lt;class Y&gt; bool operator&gt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;
16526 </pre></blockquote>
16527
16528 <p>
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&amp;</tt> instead of <tt>void</tt>. Since the note
16531 mentioned in the issue description has now already been changed to
16532 </p>
16533 <blockquote>
16534 deleted overloads close possible hole in the type system
16535 </blockquote>
16536 <p>
16537 it seems to be of even lesser need to perform the change. Therefore
16538 I recommend declaring the issue as NAD.
16539 </p>
16540 </blockquote>
16541
16542 <p><i>[
16543 Batavia (2009-05):
16544 ]</i></p>
16545
16546 <blockquote>
16547 <p>
16548 We agree with Daniel's recommendation.
16549 </p>
16550 <p>
16551 Move to NAD.
16552 </p>
16553 </blockquote>
16554
16555
16556 <p><b>Proposed resolution:</b></p>
16557 <p>
16558 Change 20.8.14.2 [func.wrap.func]
16559 </p>
16560
16561 <blockquote><pre>...
16562 private:
16563    // 20.8.14.2 [func.wrap.func], undefined operators:
16564    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
16565    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
16566 };
16567 </pre></blockquote>
16568
16569 <p>
16570 Change 20.8.14.2 [func.wrap.func]
16571 </p>
16572
16573 <blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
16574 template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
16575 </pre></blockquote>
16576
16577
16578
16579
16580
16581 <hr>
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>
16588 <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
16592 are supported".
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:
16596 </p>
16597
16598 <p>
16599 1) The members
16600 </p>
16601
16602 <blockquote><pre>const_iterator rbegin() const;
16603 const_iterator rend() const;
16604 </pre></blockquote>
16605
16606 <p>
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:
16611 </p>
16612 <p>
16613 (a) Several typedefs delegate to
16614 <tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
16615 </p>
16616 <p>
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.
16623 </p>
16624 <p>
16625 2) The new "convenience" members
16626 </p>
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>
16632 <p>
16633 should be added according to tables 80/81.
16634 </p>
16635
16636
16637 <p><b>Proposed resolution:</b></p>
16638 <p>
16639 Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
16640 para 3:
16641 </p>
16642
16643 <blockquote><pre>const_iterator cbegin() const; 
16644 const_iterator cend() const;
16645 </pre></blockquote>
16646
16647 <p>
16648 In section 28.10.4 [re.results.acc] change:
16649 </p>
16650
16651 <blockquote>
16652 <pre>const_iterator begin() const;
16653 <ins>const_iterator cbegin() const;</ins>
16654 </pre>
16655 <blockquote>
16656 <p>
16657 -7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
16658 </p>
16659 </blockquote>
16660
16661 <pre>const_iterator end() const;
16662 <ins>const_iterator cend() const;</ins>
16663 </pre>
16664 <blockquote>
16665 <p>
16666 -8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
16667 </p>
16668 </blockquote>
16669 </blockquote>
16670
16671
16672
16673 <p><i>[
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.
16677 ]</i></p>
16678
16679
16680 <p><i>[
16681 Bellevue:  Proposed wording now in the WP.
16682 ]</i></p>
16683
16684
16685
16686
16687
16688 <hr>
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>
16694 <p>
16695 28.11.3 [re.alg.search]/5 declares
16696 </p>
16697
16698 <blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
16699 bool regex_search(iterator first, iterator last,
16700                   const basic_regex&lt;charT, traits&gt;&amp; e,
16701                   regex_constants::match_flag_type flags =
16702                       regex_constants::match_default);
16703 </pre></blockquote>
16704
16705 <p>
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:
16710 </p>
16711
16712 <blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
16713 bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
16714                   const basic_regex&lt;charT, traits&gt;&amp; e,
16715                   regex_constants::match_flag_type flags =
16716                       regex_constants::match_default);
16717 </pre></blockquote>
16718
16719
16720 <p><b>Proposed resolution:</b></p>
16721 <p>
16722 In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
16723 "BidirectionalIterator"
16724 </p>
16725
16726 <blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
16727   bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last, 
16728                     const basic_regex&lt;charT, traits&gt;&amp; e, 
16729                     regex_constants::match_flag_type flags = 
16730                       regex_constants::match_default);
16731 </pre>
16732 <p>
16733 -6- <i>Effects:</i> Behaves "as if" by constructing an object what of
16734 type <tt>match_results&lt;<del>iterator</del>
16735 <ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
16736 of <tt>regex_search(first, last, what, e, flags)</tt>.
16737 </p>
16738 </blockquote>
16739
16740
16741 <p><b>Rationale:</b></p>
16742 Applied to working paper while issue was still in New status.
16743
16744
16745
16746
16747
16748 <hr>
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>
16754 <p>
16755 In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
16756 </p>
16757
16758 <blockquote>
16759 <p>
16760 <i>Effects:</i> Initializes begin and end to point to the beginning and the
16761 end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
16762 </p></blockquote>
16763
16764 <p>
16765 There are two issues with this description:
16766 </p>
16767
16768 <ol>
16769 <li>
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.
16774 </li>
16775 <li>
16776 There does not exist any parameter f, but instead a parameter
16777 m in the constructor declaration, so this is actually an editorial
16778 fix.
16779 </li>
16780 </ol>
16781
16782
16783 <p><b>Proposed resolution:</b></p>
16784 <p>
16785 In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
16786 </p>
16787
16788 <blockquote><p>
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>&amp;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.
16796 </p></blockquote>
16797
16798
16799
16800
16801
16802 <hr>
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>
16809 <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:
16812 </p>
16813 <p>
16814 1) The third constructor form is written as
16815 </p>
16816 <blockquote><pre>template &lt;std::size_t N&gt;
16817   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
16818                        const regex_type&amp; re, 
16819                        const int (&amp;submatches)[R], 
16820                        regex_constants::match_flag_type m = 
16821                          regex_constants::match_default);
16822 </pre></blockquote>
16823
16824 <p>
16825 where the dimensions of submatches are specified by an
16826 unknown value R, which should be N.
16827 </p>
16828 <p>
16829 2) Paragraph 2 of the same section says in its last sentence:
16830 </p>
16831
16832 <blockquote><p>
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>[&amp;submatches, &amp;submatches + R)</tt>.
16836 </p></blockquote>
16837
16838 <p>
16839 where again R must be replaced by N.
16840 </p>
16841
16842 <p>
16843 3) Paragraph 3 of the same section says in its first sentence:
16844 </p>
16845
16846 <blockquote><p>
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>.
16849 </p></blockquote>
16850
16851 <p>
16852 where a non-existing parameter "f" is mentioned, which must be
16853 replaced
16854 by the parameter "m".
16855 </p>
16856
16857
16858 <p><b>Proposed resolution:</b></p>
16859 <p>
16860 Change 28.12.2.1 [re.tokiter.cnstr]/1:
16861 </p>
16862 <blockquote><pre>template &lt;std::size_t N&gt;
16863   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
16864                        const regex_type&amp; re, 
16865                        const int (&amp;submatches)[<del>R</del> <ins>N</ins>], 
16866                        regex_constants::match_flag_type m = 
16867                          regex_constants::match_default);
16868 </pre></blockquote>
16869
16870 <p>
16871 Change 28.12.2.1 [re.tokiter.cnstr]/2:
16872 </p>
16873
16874 <blockquote><p>
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>[&amp;submatches, &amp;submatches +
16881 <del>R</del> <ins>N</ins>)</tt>.
16882 </p></blockquote>
16883
16884 <p>
16885 Change 28.12.2.1 [re.tokiter.cnstr]/3:
16886 </p>
16887
16888 <blockquote><p>
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.
16897 </p></blockquote>
16898
16899
16900
16901
16902
16903
16904 <hr>
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>
16911 <p>
16912 </p>
16913 <blockquote>
16914 <p>
16915 1.2 [intro.refs] Normative references
16916 </p>
16917
16918 <p>
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.
16927 </p>
16928
16929 <ul>
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
16935 Integrity</li>
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
16943 Plane</li>
16944 </ul>
16945 </blockquote>
16946
16947 <p>
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!
16950 </p>
16951 <p>
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)
16956 </p>
16957
16958 <p><i>[
16959 Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
16960 ]</i></p>
16961
16962
16963 <p><i>[
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>
16969 <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.
16973 ]</i></p>
16974
16975
16976 <p><i>[
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.
16979 ]</i></p>
16980
16981
16982
16983
16984 <p><b>Proposed resolution:</b></p>
16985
16986
16987
16988
16989
16990 <hr>
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>
16997 <p>
16998 26.5.2 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
16999 contains an unreasonable closing curly brace inside the
17000 <tt>subtract_with_carry_engine</tt> declaration.
17001 </p>
17002
17003
17004 <p><b>Proposed resolution:</b></p>
17005 <p>
17006 Change the current declaration in 26.5.2 [rand.synopsis]
17007 </p>
17008
17009 <blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
17010 class subtract_with_carry_engine;
17011 </pre></blockquote>
17012
17013
17014 <p><i>[
17015 Pete: Recommends editorial.
17016 ]</i></p>
17017
17018
17019
17020
17021
17022 <hr>
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>
17028 <p>
17029 17.6.2.2 [using.headers] states:
17030 </p>
17031
17032 <blockquote><p>
17033 A translation unit shall include a header only outside of any
17034 external declaration or definition, [...]
17035 </p></blockquote>
17036
17037 <p>
17038 I see three problems with this requirement:
17039 </p>
17040
17041 <ol type="a">
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).
17045 </p><p>
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
17051 would be legal:
17052 </p>
17053 <blockquote><pre>  // at global scope
17054   static void f()
17055   {
17056 # include &lt;cstddef&gt;
17057   }
17058
17059   static void g()
17060   {
17061 # include &lt;stddef.h&gt;
17062   }
17063 </pre></blockquote>
17064 <p>
17065 (note that while the first example is unlikely to compile correctly,
17066 the second one may well do)
17067 </p></li>
17068
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:
17072 </p>
17073 <blockquote><p>
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
17081    effect.
17082    </p>
17083 <p>                                 --James Kuyper, on comp.std.c++
17084 </p></blockquote></li>
17085
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>):
17090 </p>
17091 <blockquote><p>
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::
17096     {
17097         #include "using_ops.hpp"
17098     }
17099 </pre></blockquote>
17100 </li>
17101 </ol>
17102
17103
17104 <p><b>Proposed resolution:</b></p>
17105 <p>
17106 </p>
17107
17108
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.
17113
17114
17115
17116
17117
17118 <hr>
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>
17125 <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
17135 of view.
17136 </p>
17137 <p>
17138 Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
17139 by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
17140 </p>
17141 <blockquote><p>
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>
17146 </p></blockquote>
17147 <p>
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.
17157 </p>
17158 <p>
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
17167 being signaled.
17168 </p>
17169 <p>
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>.
17174 </p>
17175 <p>
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&gt;&gt;i&gt;&gt;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.
17183 </p>
17184 <p>
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:
17195 </p>
17196 <pre>    int i = old_i;
17197     cin &gt;&gt; i;
17198     if (cin.fail())
17199         // can the value of i be trusted?
17200         // what does it mean if i == old_i?
17201         // ...
17202 </pre>
17203 <p>
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.
17212 </p>
17213
17214
17215 <p><b>Proposed resolution:</b></p>
17216
17217 <p>
17218 Change 22.4.2.1.2 [facet.num.get.virtuals]:
17219 </p>
17220
17221 <blockquote>
17222 <p>
17223 <b>Stage 3:</b> The result of stage 2 processing can be one of
17224 </p>
17225 <ul>
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>
17227
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>
17229 </ul>
17230 <p>
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&lt;numpunct&lt;charT&gt; &gt;(<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>
17232 </p>
17233 </blockquote>
17234
17235
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.
17240
17241
17242
17243
17244
17245 <hr>
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>
17252 <p>
17253 17.5.1.4 [structure.specifications] para 5 says
17254 </p>
17255
17256 <blockquote><p>
17257 -5- Complexity requirements specified in the library
17258 clauses are upper bounds, and implementations that provide better
17259 complexity guarantees satisfy the requirements.
17260 </p></blockquote>
17261
17262 <p>
17263 The following
17264 objection has been raised:
17265 </p>
17266
17267 <blockquote><p>
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.
17274 </p></blockquote>
17275
17276 <p>
17277 [Plum ref
17278 _23213Y31 etc]
17279 </p>
17280
17281
17282 <p><b>Proposed resolution:</b></p>
17283 <p>
17284 </p>
17285
17286
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.
17290
17291
17292
17293
17294
17295 <hr>
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>
17302 <p>
17303 22.4.6.1.2 [locale.money.get.virtuals], para 1 says:
17304 </p>
17305
17306 <blockquote><p>
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>.
17311 </p></blockquote>
17312
17313 <p>
17314 The following
17315 objection has been raised:
17316 </p>
17317
17318 <blockquote><p>
17319 Some implementations interpret this to mean that a facet derived from
17320 <tt>ctype&lt;wchar_t&gt;</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?
17326 </p></blockquote>
17327
17328 <p>
17329 [Plum ref _222612Y14]
17330 </p>
17331
17332 <p>
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]
17335 </p>
17336
17337 <p><i>[
17338 Kona (2007): Bill and Dietmar to provide proposed wording.
17339 ]</i></p>
17340
17341
17342 <p><i>[
17343 post Bellevue: Bill adds:
17344 ]</i></p>
17345
17346
17347 <blockquote>
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.
17352 </blockquote>
17353
17354 <p><i>[
17355 Batavia (2009-05):
17356 ]</i></p>
17357
17358 <blockquote>
17359 We agree with Bill's comment above,
17360 in line with the first of the interpretations offered in the issue.
17361 Move to NAD.
17362 </blockquote>
17363
17364
17365 <p><b>Proposed resolution:</b></p>
17366 <p>
17367 </p>
17368
17369
17370
17371
17372
17373 <hr>
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>
17380 <p>
17381 22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
17382 </p>
17383
17384 <blockquote><p>
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.
17388 </p></blockquote>
17389
17390 <p>
17391 The following objection has been raised:
17392 </p>
17393
17394 <blockquote><p>
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".
17398 </p></blockquote>
17399
17400 <p>
17401 [Plum ref _222612Y32]
17402 </p>
17403
17404 <p><i>[
17405 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
17406 ]</i></p>
17407
17408
17409 <p>
17410 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.
17411 </p>
17412
17413 <p><i>[
17414 2009-05-17 Howard adds:
17415 ]</i></p>
17416
17417
17418 <blockquote>
17419 <p>
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:
17423 </p>
17424
17425 <blockquote>
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
17433 positive sign.
17434 </blockquote>
17435
17436 <p>
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() &gt;
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>.
17443 For example:
17444 </p>
17445
17446 <blockquote><pre>pattern = {symbol, sign, value, none}
17447 positive_sign = "+"
17448 negative_sign = ""
17449 $123   // a negative value, using optional sign
17450 $+123  // a positive value
17451 $-123  // a parse error
17452 </pre></blockquote>
17453
17454 <p>
17455 And:
17456 </p>
17457
17458 <blockquote><pre>pattern = {symbol, sign, value, none}
17459 positive_sign = ""
17460 negative_sign = ""
17461 $123   // a positive value, no sign possible
17462 $+123  // a parse error
17463 $-123  // a parse error
17464 </pre></blockquote>
17465
17466
17467 <p>
17468 And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>):
17469 </p>
17470
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>
17478
17479
17480 <p>
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.
17484 </p>
17485 </blockquote>
17486
17487 <p><i>[
17488 Batavia (2009-05):
17489 ]</i></p>
17490
17491 <blockquote>
17492 <p>
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.
17497 </p>
17498 <p>
17499 Alan would like to rewrite paragraph 3.
17500 </p>
17501 <p>
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.
17506 </p>
17507 </blockquote>
17508
17509 <p><i>[
17510 2009-07-14 Alan reopens with improved wording.
17511 ]</i></p>
17512
17513
17514 <p><i>[
17515 2009-07 Frankfurt
17516 ]</i></p>
17517
17518
17519 <blockquote>
17520 No consensus for closing as NAD.  Leave in Review.
17521 </blockquote>
17522
17523 <p><i>[
17524 2009-10 Santa Cruz:
17525 ]</i></p>
17526
17527
17528 <blockquote>
17529 NAD.  Agreed that the original assessment as NAD was correct.
17530 </blockquote>
17531
17532
17533
17534 <p><b>Proposed resolution:</b></p>
17535 <p>
17536 Change 22.4.6.1.2 [locale.money.get.virtuals] p3:
17537 </p>
17538
17539 <blockquote>
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>
17556
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. 
17566 If any sign
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>
17574 </blockquote>
17575
17576
17577
17578
17579
17580 <hr>
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>
17587 <p>
17588 22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
17589 </p>
17590
17591 <blockquote><p>
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.
17594 </p></blockquote>
17595
17596 <p>
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:
17600 </p>
17601
17602 <blockquote><p>
17603 The input can successfully match only a positive sign, so the negative
17604 pattern is an unsuccessful match.
17605 </p></blockquote>
17606
17607 <p>
17608 [Plum ref _222612Y34, 222612Y51b]
17609 </p>
17610
17611 <p><i>[
17612 Bill to provide proposed wording and interpretation of existing wording.
17613 ]</i></p>
17614
17615
17616 <p><i>[
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>.
17618 ]</i></p>
17619
17620
17621 <p><i>[
17622 Batavia (2009-05):
17623 ]</i></p>
17624
17625 <blockquote>
17626 <p>
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.
17631 </p>
17632 <p>
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.
17637 </p>
17638 </blockquote>
17639
17640
17641 <p><b>Proposed resolution:</b></p>
17642 <p>
17643 </p>
17644
17645
17646
17647
17648
17649 <hr>
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>
17656 <p>
17657 22.4.6.3 [locale.moneypunct], para 2 says:
17658 </p>
17659
17660 <blockquote><p>
17661 The value <tt>space</tt> indicates that at least one space is required at 
17662 that position.
17663 </p></blockquote>
17664
17665 <p>
17666 The following objection has been raised:
17667 </p>
17668
17669 <blockquote><p>
17670 Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
17671 </p></blockquote>
17672
17673 <p>
17674 [Plum ref _22263Y22]
17675 </p>
17676
17677 <p><i>[
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.
17681 ]</i></p>
17682
17683
17684
17685
17686 <p><b>Proposed resolution:</b></p>
17687
17688
17689
17690
17691
17692 <hr>
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>
17699 <p>
17700 28.12.2 [re.tokiter], p3 says:
17701 </p>
17702 <blockquote>
17703 <p>
17704 After it is constructed, the iterator finds and stores a value
17705 <tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
17706 internal count <tt>N</tt> to zero.
17707 </p>
17708 </blockquote>
17709
17710 <p>
17711 Should read:
17712 </p>
17713
17714 <blockquote>
17715 <p>
17716 After it is constructed, the iterator finds and stores a value
17717 <tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
17718 position and sets the internal count <tt>N</tt> to zero.
17719 </p>
17720 </blockquote>
17721
17722 <p><i>[
17723 John adds:
17724 ]</i></p>
17725
17726
17727 <blockquote><p>
17728 Yep, looks like a typo/administrative fix to me.
17729 </p></blockquote>
17730
17731
17732
17733 <p><b>Proposed resolution:</b></p>
17734 <p>
17735 </p>
17736
17737
17738
17739
17740
17741 <hr>
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>
17748 <p>
17749 In 28.4 [re.syn] of N2284, two template functions 
17750 are declared here: 
17751 </p>
17752 <blockquote><pre>// 28.10, class template match_results: 
17753   &lt;<i>snip</i>&gt;
17754 // match_results comparisons 
17755   template &lt;class BidirectionalIterator, class Allocator&gt; 
17756     bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17757                      const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
17758   template &lt;class BidirectionalIterator, class Allocator&gt; 
17759     bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17760                      const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
17761
17762 // 28.10.6, match_results swap:
17763 </pre></blockquote>
17764
17765 <p>
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.
17769 </p>
17770
17771 <p><i>[
17772 John adds:
17773 ]</i></p>
17774
17775
17776 <blockquote><p>
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
17779 copy of the other.
17780 </p></blockquote>
17781
17782 <p><i>[
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>.
17785 ]</i></p>
17786
17787
17788
17789 <p><b>Proposed resolution:</b></p>
17790 <p>
17791 Add a new section after 28.10.7 [re.results.swap], which reads:
17792 </p>
17793 <p>
17794 28.10.7 match_results non-member functions.
17795 </p>
17796
17797 <blockquote>
17798 <pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17799   bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17800                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17801 </pre>
17802 <blockquote>
17803 <p>
17804 <i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
17805 </p>
17806 </blockquote>
17807 </blockquote>
17808
17809 <blockquote>
17810 <pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17811   bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17812                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17813 </pre>
17814 <blockquote>
17815 <p>
17816 <i>Returns:</i> <tt>!(m1 == m2)</tt>.
17817 </p>
17818 </blockquote>
17819 </blockquote>
17820
17821 <blockquote>
17822 <pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17823   void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17824             match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17825 </pre>
17826 <blockquote>
17827 <p>
17828 <i>Returns:</i> <tt>m1.swap(m2)</tt>.
17829 </p>
17830 </blockquote>
17831 </blockquote>
17832
17833
17834 <p><i>[
17835 Bellevue:  Proposed wording now in WP.
17836 ]</i></p>
17837
17838
17839
17840
17841
17842 <hr>
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>
17848 <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
17853 </p>
17854 <blockquote><p>
17855 The return type shall not be convertible to <tt>int</tt>.
17856 </p></blockquote>
17857 <p>
17858 This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
17859 </p>
17860
17861 <p><i>[
17862 Bellevue:
17863 ]</i></p>
17864
17865
17866 <blockquote>
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.
17870 </blockquote>
17871
17872
17873
17874 <p><b>Proposed resolution:</b></p>
17875 <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:
17878 </p>
17879 <blockquote><p>
17880 The return type shall not be convertible to <tt>int</tt>.
17881 </p></blockquote>
17882
17883
17884 <p><i>[
17885 Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
17886 ]</i></p>
17887
17888
17889
17890
17891
17892 <hr>
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>
17899 <p>
17900 Quoting the latest draft (n2135), 26.8 [c.math]: 
17901 </p>
17902
17903 <blockquote>
17904 <p>
17905 The added signatures are:
17906 </p>
17907 <blockquote><pre>long abs(long); // labs()
17908 long abs(long long); // llabs()
17909 </pre></blockquote>
17910 </blockquote>
17911 <p>
17912 Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
17913 </p>
17914
17915
17916 <p><b>Proposed resolution:</b></p>
17917 <p>
17918 Change 26.8 [c.math]: 
17919 </p>
17920 <blockquote><pre><ins>long </ins>long abs(long long); // llabs()
17921 </pre></blockquote>
17922
17923
17924 <p><b>Rationale:</b></p>
17925 Had already been fixed in the WP by the time the LWG reviewed this.
17926
17927
17928
17929
17930
17931 <hr>
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>
17937 <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 &gt; -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 &amp; 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
17950 dimensions.
17951 </p>
17952 <p>
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>.
17958 </p>
17959
17960 <p><i>[
17961 Batavia (2009-05):
17962 ]</i></p>
17963
17964 <blockquote>
17965 <p>
17966 We understand the issue, and have opted not to extend as recommended.
17967 </p>
17968 <p>
17969 Move to NAD.
17970 </p>
17971 </blockquote>
17972
17973
17974 <p><b>Proposed resolution:</b></p>
17975 <p>
17976 </p>
17977
17978
17979
17980
17981
17982 <hr>
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>
17988 <p>
17989 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
17990 <tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
17991
17992 <p><i>[
17993 Batavia (2009-05):
17994 ]</i></p>
17995
17996 <blockquote>
17997 <p>
17998 The error has been corrected in the pending IS.
17999 </p>
18000 <p>
18001 Move to NAD.
18002 </p>
18003 </blockquote>
18004
18005
18006 <p><b>Proposed resolution:</b></p>
18007 <p>
18008 </p>
18009
18010
18011
18012
18013
18014 <hr>
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>
18022
18023 <p>
18024 From the Toronto Core wiki:
18025 </p>
18026
18027 <p>
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".
18033 </p>
18034
18035 <p>
18036 Peter's response:
18037 </p>
18038
18039 <p>
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.
18043 </p>
18044
18045 <p><i>[
18046 Bellevue:
18047 ]</i></p>
18048
18049
18050 <blockquote>
18051 <p>
18052 Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
18053 </p>
18054 <p>
18055 Even simpler now with nullptr_t.
18056 </p>
18057 <p>
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.
18061 </p>
18062 </blockquote>
18063
18064
18065
18066 <p><b>Proposed resolution:</b></p>
18067 <p>
18068 </p>
18069
18070
18071
18072
18073
18074 <hr>
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>
18081 <p>
18082 The POSIX "Extended API Set Part 4,"
18083 </p>
18084 <blockquote><p>
18085 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
18086 </p></blockquote>
18087 <p>
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.
18092 </p>
18093 <p>
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>.
18098 </p>
18099 <p>
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.
18103 </p>
18104 <p>
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>.
18107 </p>
18108
18109 <p><i>[
18110 Kona (2007): Bill and Nick to provide wording.
18111 ]</i></p>
18112
18113
18114 <p><i>[
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>.
18118 ]</i></p>
18119
18120
18121 <p><i>[
18122 2009-07 Frankfurt:
18123 ]</i></p>
18124
18125
18126 <blockquote>
18127 <p>
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.
18130 </p>
18131 <p>
18132 Move to NAD Future.
18133 </p>
18134 </blockquote>
18135
18136
18137
18138 <p><b>Proposed resolution:</b></p>
18139 <p>
18140 </p>
18141
18142
18143
18144
18145
18146 <hr>
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>
18153 <p>
18154 Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
18155 changed to <tt>const T&amp;</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
18157 incompletely
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.
18161 </p>
18162
18163
18164 <p><b>Proposed resolution:</b></p>
18165 <p>
18166 Change 26.6.2.3 [valarray.access]:
18167 </p>
18168
18169 <blockquote>
18170 <p>
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.
18175 </p>
18176
18177 <p>
18178 -3- The expression <tt>&amp;a[i+j] == &amp;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>.
18181 </p>
18182
18183 <p>
18184 -4- Likewise, the expression <tt>&amp;a[i] != &amp;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>
18191 </p>
18192
18193 <p>
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.
18197 </p>
18198
18199 </blockquote>
18200
18201
18202
18203
18204
18205
18206 <hr>
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>
18213 <p>
18214 Paragraph 21.4 [basic.string]/3 states:
18215 </p>
18216
18217 <blockquote>
18218 <p>
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).
18221 </p>
18222 </blockquote>
18223
18224 <p>
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.
18229 </p>
18230
18231 <p><i>[
18232 Bellevue:
18233 ]</i></p>
18234
18235
18236 <blockquote>
18237 <ul>
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>
18241 </ul>
18242 <ul>
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:
18246 <ul>
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>
18251 </ul>
18252 </li>
18253 </ul>
18254 General consensus is to suggest option 2.
18255 </blockquote>
18256
18257 <p><i>[
18258 2009-07 Frankfurt:
18259 ]</i></p>
18260
18261
18262 <blockquote>
18263 Move to NAD Editorial
18264 </blockquote>
18265
18266
18267
18268 <p><b>Proposed resolution:</b></p>
18269 <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.
18273 </p>
18274
18275
18276
18277
18278
18279 <hr>
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>
18286 <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).
18290 </p>
18291
18292 <p>
18293 How are we going to explain this code to beginning programmers?
18294 </p>
18295
18296 <blockquote><pre>template&lt;class I, class E, class S&gt;
18297 struct codecvt : std::codecvt&lt;I, E, S&gt;
18298 {
18299     ~codecvt()
18300     { }
18301 };
18302
18303 void main()
18304 {
18305     std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
18306     
18307     std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
18308 }
18309 </pre></blockquote>
18310
18311 <p><i>[
18312 San Francisco:
18313 ]</i></p>
18314
18315
18316 <blockquote>
18317 Bill will propose a resolution.
18318 </blockquote>
18319
18320 <p><i>[
18321 2009-07 Frankfurt:
18322 ]</i></p>
18323
18324
18325 <blockquote>
18326 <p>
18327 codecvt isn't intended for beginning programmers. This is a regrettable
18328 consequence of the original design of the facet.
18329 </p>
18330 <p>
18331 Move to NAD.
18332 </p>
18333 </blockquote>
18334
18335
18336 <p><b>Proposed resolution:</b></p>
18337 <p>
18338 </p>
18339
18340
18341
18342
18343
18344 <hr>
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>
18351 <p>
18352 Table 90: (Optional sequence container operations) states the
18353 "assertion note pre/post-condition" of <tt>operator[]</tt> to be
18354 </p>
18355
18356 <blockquote><pre>*(a.begin() + n)
18357 </pre></blockquote>
18358
18359 <p>
18360 Surely that's meant to be "operational semantics?"
18361 </p>
18362
18363
18364
18365 <p><b>Proposed resolution:</b></p>
18366 <blockquote>
18367 <table border="1">
18368 <caption>Table 90: Optional sequence container operations</caption>
18369 <tbody><tr>
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>
18371 </tr>
18372 </tbody></table>
18373 </blockquote>
18374
18375
18376
18377
18378
18379
18380 <hr>
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>
18387 <p>
18388 Two overloads of <tt>regex_replace()</tt> are currently provided:
18389 </p>
18390
18391 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator, 
18392     class traits, class charT&gt; 
18393   OutputIterator 
18394   regex_replace(OutputIterator out, 
18395                 BidirectionalIterator first, BidirectionalIterator last, 
18396                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18397                 const basic_string&lt;charT&gt;&amp; fmt, 
18398                 regex_constants::match_flag_type flags = 
18399                   regex_constants::match_default);
18400  
18401 template &lt;class traits, class charT&gt; 
18402   basic_string&lt;charT&gt; 
18403   regex_replace(const basic_string&lt;charT&gt;&amp; s, 
18404                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18405                 const basic_string&lt;charT&gt;&amp; fmt, 
18406                 regex_constants::match_flag_type flags = 
18407                   regex_constants::match_default);
18408 </pre></blockquote>
18409
18410 <ol>
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>
18413 <li>
18414 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
18415
18416 <blockquote><pre>const string s("kitten");
18417 const regex r("en");
18418 cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
18419 </pre></blockquote>
18420
18421 <p>
18422 The compiler error message will be something like "could not deduce
18423 template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
18424 char[1]'".
18425 </p>
18426
18427 <p>
18428 Users expect that anything taking a <tt>basic_string&lt;charT&gt;</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).
18435 </p>
18436
18437 <p>
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.
18444 </p>
18445 </li>
18446
18447 <li>
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>.)
18454 </li>
18455 </ol>
18456
18457 <p><i>[
18458 Sophia Antipolis:
18459 ]</i></p>
18460
18461
18462 <blockquote>
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.
18467 </blockquote>
18468
18469 <p><i>[
18470 2009-07 Frankfurt:
18471 ]</i></p>
18472
18473
18474 <blockquote>
18475 Daniel to tweak for us.
18476 </blockquote>
18477
18478 <p><i>[
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>.
18480 ]</i></p>
18481
18482
18483 <blockquote>
18484 <p>
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>.
18486 </p>
18487 </blockquote>
18488
18489 <p><i>[
18490 2009-10 Santa Cruz:
18491 ]</i></p>
18492
18493
18494 <blockquote>
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>.
18497 </blockquote>
18498
18499 <p><i>[
18500 2010-01-27 Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
18501 Rationale added below.
18502 ]</i></p>
18503
18504
18505
18506 <p><b>Rationale:</b></p>
18507 <p>
18508 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>.
18509 </p>
18510
18511
18512 <p><b>Proposed resolution:</b></p>
18513
18514 <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]:
18520 </p>
18521
18522 <blockquote>
18523 <pre>template &lt;class OutputIterator, class BidirectionalIterator, 
18524     class traits, class charT&gt; 
18525   OutputIterator 
18526   regex_replace(OutputIterator out, 
18527                 BidirectionalIterator first, BidirectionalIterator last, 
18528                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18529                 const basic_string&lt;charT&gt;&amp; fmt, 
18530                 regex_constants::match_flag_type flags = 
18531                   regex_constants::match_default);
18532
18533 <ins>template &lt;class OutputIterator, class BidirectionalIterator, 
18534     class traits, class charT&gt; 
18535   OutputIterator 
18536   regex_replace(OutputIterator out, 
18537                 BidirectionalIterator first, BidirectionalIterator last, 
18538                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18539                 const charT* fmt, 
18540                 regex_constants::match_flag_type flags = 
18541                   regex_constants::match_default);</ins>
18542 </pre>
18543 <p>...</p>
18544 <pre>template &lt;class traits, class charT&gt; 
18545   basic_string&lt;charT&gt; 
18546   regex_replace(const basic_string&lt;charT&gt;&amp; s, 
18547                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18548                 const basic_string&lt;charT&gt;&amp; fmt, 
18549                 regex_constants::match_flag_type flags = 
18550                   regex_constants::match_default);
18551
18552 <ins>template &lt;class traits, class charT&gt; 
18553   basic_string&lt;charT&gt; 
18554   regex_replace(const basic_string&lt;charT&gt;&amp; s, 
18555                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18556                 const charT* fmt, 
18557                 regex_constants::match_flag_type flags = 
18558                   regex_constants::match_default);</ins>
18559
18560 <ins>template &lt;class traits, class charT&gt; 
18561   basic_string&lt;charT&gt; 
18562   regex_replace(const charT* s, 
18563                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18564                 const basic_string&lt;charT&gt;&amp; fmt, 
18565                 regex_constants::match_flag_type flags = 
18566                   regex_constants::match_default);</ins>
18567
18568 <ins>template &lt;class traits, class charT&gt; 
18569   basic_string&lt;charT&gt; 
18570   regex_replace(const charT* s, 
18571                 const basic_regex&lt;charT, traits&gt;&amp; e, 
18572                 const charT* fmt, 
18573                 regex_constants::match_flag_type flags = 
18574                   regex_constants::match_default);</ins>
18575 </pre>
18576 </blockquote>
18577
18578
18579
18580
18581
18582
18583 <hr>
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>
18590 <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&lt;X::result_type&gt;(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.
18601 </p>
18602
18603 <p>
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&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an 
18606 implementation specific unsigned integer type."
18607 </p>
18608
18609 <p>
18610 Additionally, the definition of s in 26.5.1.4 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
18611 </p>
18612
18613 <p>
18614 Similarly, the type of the seed in 26.5.1.5 [rand.req.adapt]/3 e) could be left unspecified.
18615 </p>
18616
18617 <p>
18618 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18619 for further discussion.
18620 </p>
18621
18622 <p><i>[
18623 Stephan Tolksdorf adds pre-Bellevue:
18624 ]</i></p>
18625
18626
18627 <blockquote>
18628 <p>
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:
18632 </p>
18633 <p>
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&lt;X::result_type&gt;(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.
18644 </p>
18645 </blockquote>
18646
18647 <p><i>[
18648 Bellevue:
18649 ]</i></p>
18650
18651
18652 <blockquote>
18653 Propose close NAD for the reasons given in N2424.
18654 </blockquote>
18655
18656
18657
18658
18659 <p><b>Proposed resolution:</b></p>
18660 <p>
18661 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18662 for further discussion.
18663 </p>
18664
18665 <p><i>[
18666 Stephan Tolksdorf adds pre-Bellevue:
18667 ]</i></p>
18668
18669
18670 <blockquote>
18671 <p>
18672 Change row 3 of table 105 "Random number engine requirements" in 26.5.1.4 [rand.req.eng]/3
18673 </p>
18674
18675 <blockquote>
18676 Creates an engine with initial state determined by
18677 <tt><del>static_cast&lt;X::result_type&gt;(</del>s<del>)</del></tt>
18678 </blockquote>
18679
18680 <p>
18681 Similarly, change 26.5.1.5 [rand.req.adapt]/3 e)
18682 </p>
18683
18684 <blockquote>
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>, ...
18687 </blockquote>
18688
18689 </blockquote>
18690
18691
18692
18693
18694
18695
18696 <hr>
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>
18702 <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.
18711 </p>
18712
18713 <p>
18714 <b>Posssible resolution:</b> [As above]
18715 </p>
18716
18717 <p>
18718 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18719 for further discussion.
18720 </p>
18721
18722 <p><i>[
18723 Bellevue:
18724 ]</i></p>
18725
18726
18727 <blockquote>
18728 Close NAD for the reasons given in N2424.
18729 </blockquote>
18730
18731
18732
18733 <p><b>Proposed resolution:</b></p>
18734 <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.
18737 </p>
18738
18739
18740
18741
18742
18743 <hr>
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>
18750 <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. 
18756 </p>
18757 <p>
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 
18760 changes:
18761 </p>
18762
18763 <p>
18764 <b>Possible resolution:</b>
18765 </p>
18766
18767 <ol type="a">
18768 <li>
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).
18773 </li>
18774 <li>
18775 Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
18776 </li>
18777 <li>
18778 <p>
18779 Supplement the <tt>seed_seq</tt> with a traits class
18780 </p>
18781 <blockquote><pre>template &lt;typename T&gt; 
18782 struct is_seed_seq { static const bool value = false; }
18783 </pre></blockquote>
18784 <p>and the specialization</p>
18785 <blockquote><pre>template &lt;&gt; 
18786 struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
18787 </pre></blockquote>
18788 <p>which users can supplement with further specializations.</p>
18789 </li>
18790 <li>
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).
18794 </li>
18795 </ol>
18796
18797 <p><i>[
18798 Bellevue:
18799 ]</i></p>
18800
18801
18802 <blockquote>
18803 See N2424. Close NAD but note that "conceptizing" the library may cause
18804 this problem to be solved by that route.
18805 </blockquote>
18806
18807
18808 <p><b>Proposed resolution:</b></p>
18809 <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.
18812 </p>
18813
18814
18815
18816
18817
18818 <hr>
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>
18826 <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 
18835 nightmare.
18836 </p>
18837
18838 <p>
18839 <b>Possible resolution:</b> For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
18840 </p>
18841
18842 <p><i>[
18843 Bellevue:
18844 ]</i></p>
18845
18846
18847 <blockquote>
18848 <p>
18849 Disagreement persists.
18850 </p>
18851 <p>
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.
18858 </p>
18859 <p>
18860 Correction: The formula above should instead read 1+sin(n*x).
18861 </p>
18862 <p>
18863 Objector proposes the following possible compromise positions:
18864 </p>
18865 <ul>
18866 <li>
18867 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
18868 </li>
18869 <li>
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.
18871 </li>
18872 </ul>
18873 </blockquote>
18874
18875
18876
18877 <p><b>Proposed resolution:</b></p>
18878 <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.
18881 </p>
18882
18883
18884 <p><b>Rationale:</b></p>
18885 Addressed by
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".
18887
18888
18889
18890
18891
18892 <hr>
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>
18898 <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.]
18906 </p>
18907
18908 <p>
18909 <b>Proposed resolution:</b> I propose to drop this requirement.
18910 </p>
18911
18912 <p><i>[
18913 Bellevue:
18914 ]</i></p>
18915
18916
18917 <blockquote>
18918 Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
18919 </blockquote>
18920
18921
18922
18923 <p><b>Proposed resolution:</b></p>
18924 <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.
18927 </p>
18928
18929
18930
18931
18932
18933 <hr>
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>
18939 <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.
18945 </p>
18946
18947 <p>
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.
18950 </p>
18951
18952 <p>
18953 Choosing unusual names for the parameters causes confusion among users and makes the 
18954 interface unnecessarily inconvenient to use.
18955 </p>
18956
18957 <p>
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>.
18960 </p>
18961
18962 <p><i>[
18963 Bellevue:
18964 ]</i></p>
18965
18966
18967 <blockquote>
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.
18970 </blockquote>
18971
18972
18973 <p><b>Proposed resolution:</b></p>
18974 <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.
18977 </p>
18978
18979
18980
18981
18982
18983 <hr>
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>
18990 <ol type="a">
18991 <li>
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.
19000 </li>
19001 <li>
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.
19004 </li>
19005 </ol>
19006
19007 <p>
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.
19011 </p>
19012
19013 <p><i>[
19014 Stephan Tolksdorf adds pre-Bellevue:
19015 ]</i></p>
19016
19017
19018 <blockquote>
19019 <p>
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>
19022 of this issue:
19023 </p>
19024 <p>
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 &lt; n &lt;=
19035 numeric_limits&lt;IntType&gt;::max() + 1</tt>" makes the implementation
19036 unnecessarily complicated, "<tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>"
19037 would be better.
19038 </p>
19039 </blockquote>
19040
19041 <p><i>[
19042 Bellevue:
19043 ]</i></p>
19044
19045
19046 <blockquote>
19047 <p>
19048 In N2424. We agree with the observation and the proposed resolution to
19049 part b). We recommend the wording n &gt; 0 be replaced with 0 &lt; 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.
19054 </p>
19055
19056 <p>
19057 As it stands now, it is convenient, and the changes proposed make it
19058 much less so.
19059 </p>
19060
19061 <p>
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
19064 here.
19065 </p>
19066 </blockquote>
19067
19068
19069 <p><b>Proposed resolution:</b></p>
19070 <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.
19073 </p>
19074
19075 <p><i>[
19076 Stephan Tolksdorf adds pre-Bellevue:
19077 ]</i></p>
19078
19079
19080 <blockquote>
19081 <p>
19082 In 26.5.8.5.1 [rand.dist.samp.discrete]:
19083 </p>
19084
19085 <p>
19086 Proposed wording a):
19087 </p>
19088
19089 <blockquote>
19090 <p>
19091 Changae in para. 2
19092 </p>
19093
19094 <blockquote>
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>
19096 </blockquote>
19097
19098 <p>
19099 and change in para. 5
19100 </p>
19101
19102 <blockquote>
19103 <i>Returns:</i> A <tt>vector&lt;double&gt;</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,
19107 ..., n-1</tt>
19108 </blockquote>
19109
19110 </blockquote>
19111
19112 <p>
19113 Proposed wording b):
19114 </p>
19115
19116 <blockquote>
19117 <p>
19118 Change in para. 3:
19119 </p>
19120
19121 <blockquote>
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>&gt; 0</del></tt> 
19125 <ins>such that <tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::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>]
19129 </blockquote>
19130
19131 </blockquote>
19132
19133 </blockquote>
19134
19135
19136
19137
19138
19139 <hr>
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>
19146 <ol type="a">
19147 <li>
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>.
19150 </li>
19151 <li>
19152 <p>
19153 The design of the constructor
19154 </p>
19155 <blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt; 
19156 piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
19157                                  InputIteratorW firstW);
19158 </pre></blockquote>
19159 <p>
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.
19163 </p>
19164 </li>
19165 </ol>
19166
19167 <p>
19168 <b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
19169 </p>
19170
19171 <p><i>[
19172 Stephan Tolksdorf adds pre-Bellevue:
19173 ]</i></p>
19174
19175 <blockquote>
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>.
19179 </blockquote>
19180
19181 <p><i>[
19182 Bellevue:
19183 ]</i></p>
19184
19185
19186 <blockquote>
19187 In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
19188 </blockquote>
19189
19190
19191 <p><b>Proposed resolution:</b></p>
19192 <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.
19195 </p>
19196
19197 <p><i>[
19198 Stephan Tolksdorf adds pre-Bellevue:
19199 ]</i></p>
19200
19201
19202 <blockquote>
19203 <p>
19204 In 26.5.8.5.2 [rand.dist.samp.pconst]:
19205 </p>
19206
19207 <p>
19208 Proposed wording a)
19209 </p>
19210
19211 <blockquote>
19212 <p>
19213 Change in para. 2
19214 </p>
19215 <blockquote>
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>
19218 </blockquote>
19219
19220 <p>
19221 and change in para. 5
19222 </p>
19223
19224 <blockquote>
19225 A <tt>vector&lt;result_type&gt;</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>
19229 </blockquote>
19230
19231 </blockquote>
19232
19233 <p>
19234 Proposed wording b)
19235 </p>
19236
19237 <blockquote>
19238 <p>
19239 Change both occurrences of
19240 </p>
19241
19242 <blockquote>
19243 "piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
19244                                  InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
19245 </blockquote>
19246
19247 <p>
19248 and change in para. 3
19249 </p>
19250
19251 <blockquote>
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 &gt;= 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>
19257 </blockquote>
19258
19259 </blockquote>
19260
19261
19262 </blockquote>
19263
19264
19265
19266
19267
19268
19269 <hr>
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>
19276 <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.
19279 </p>
19280
19281
19282 <p><b>Proposed resolution:</b></p>
19283 <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.
19286 </p>
19287
19288
19289
19290
19291
19292 <hr>
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>
19299 <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)).
19304 </p>
19305
19306 <p>
19307 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
19308 for further discussion.
19309 </p>
19310
19311 <p><i>[
19312 Bellevue:
19313 ]</i></p>
19314
19315
19316 <blockquote>
19317 In N2424. Close NAD as described there.
19318 </blockquote>
19319
19320
19321
19322 <p><b>Proposed resolution:</b></p>
19323 <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.
19326 </p>
19327
19328
19329
19330
19331
19332 <hr>
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>
19339 <p>
19340 The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
19341 </p>
19342
19343 <p>
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:
19346 </p>
19347
19348 <blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
19349 </pre></blockquote>
19350
19351 <p>
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.
19362 </p>
19363
19364 <b>Possible proposed resolutions:</b>
19365
19366 <p>
19367 Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</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):
19370 </p>
19371
19372 <ol type="A">
19373 <li>
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>.
19377
19378 <blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
19379 </pre></blockquote>
19380 </li>
19381 <li>
19382 Just remove the function.
19383 </li>
19384 </ol>
19385
19386 <p>
19387 Alberto Ganesh Barbati adds:
19388 </p>
19389
19390 <ol type="A" start="3">
19391 <li>
19392 <p>
19393 Replace it with two functions:
19394 </p>
19395 <blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
19396 template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
19397 </pre></blockquote>
19398
19399 <p>
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.
19404 </p>
19405 </li>
19406 </ol>
19407
19408 <p>
19409 Peter Dimov adds:
19410 </p>
19411
19412 <blockquote>
19413 <p>
19414 My favorite option is "not a defect". A, B and C break useful code.
19415 </p>
19416 </blockquote>
19417
19418 <p><i>[
19419 Bellevue:
19420 ]</i></p>
19421
19422
19423 <blockquote>
19424 Concern this is similar to confusing "pointer to const" with "a constant pointer".
19425 </blockquote>
19426
19427
19428 <p><b>Proposed resolution:</b></p>
19429 <p>
19430 </p>
19431
19432
19433
19434
19435
19436 <hr>
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>
19444 <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.
19449 </p>
19450 <p>
19451 (Peter Dimov suggests NAD)
19452 </p>
19453
19454 <p><i>[
19455 Bellevue: 
19456 ]</i></p>
19457
19458
19459 <blockquote>
19460 <p>
19461 How could this be implemented in a way that the dynamic type is cloned?
19462 </p>
19463 <p>
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
19466 slicing involved.
19467 </p>
19468 </blockquote>
19469
19470
19471 <p><b>Proposed resolution:</b></p>
19472 <p>
19473 </p>
19474
19475
19476
19477
19478
19479 <hr>
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>
19486 <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>:
19492 </p>
19493 <blockquote><p>
19494 or <tt>T</tt> is a class type with a default constructor that is known not to throw
19495 any exceptions
19496 </p></blockquote>
19497 <p>
19498 What level of magic do we expect to deduce if this is known?
19499 </p>
19500 <p>
19501 E.g.
19502 </p>
19503
19504 <blockquote><pre>struct test{
19505  int x;
19506  test() : x() {}
19507 };
19508 </pre></blockquote>
19509 <p>
19510 Should I expect a conforming compiler to 
19511  <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
19512 </p>
19513 <p>
19514 Is this a QoI issue?
19515 </p>
19516 <p>
19517 Should I expect to 'know' only if-and-only-if there is an inline definition
19518 available?
19519 </p>
19520 <p>
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?
19523 </p>
19524 <p>
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.
19527 </p>
19528 <p>
19529 (agreement since is that trivial ops and explicit no-throws are required.
19530 Open if QoI should be allowed to detect further)
19531 </p>
19532
19533 <p><i>[
19534 Bellevue:
19535 ]</i></p>
19536
19537
19538 <blockquote>
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.
19542 </blockquote>
19543
19544 <p><i>[
19545 2009-07 Frankfurt:
19546 ]</i></p>
19547
19548
19549 <blockquote>
19550 <p>
19551 This is QoI.
19552 </p>
19553 <p>
19554 Move to NAD.
19555 </p>
19556 </blockquote>
19557
19558
19559 <p><b>Proposed resolution:</b></p>
19560 <p>
19561 </p>
19562
19563
19564
19565
19566
19567 <hr>
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>
19574 <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?
19577 </p>
19578 <p>
19579 For instance, is the following (non-polymorphic) type considered abstract?
19580 </p>
19581 <blockquote><pre>struct abstract {
19582 protected:
19583  abstract(){}
19584  abstract( abstract const &amp; ) {}
19585  ~abstract() {}
19586 };
19587 </pre></blockquote>
19588 <p>
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)
19591 </p>
19592
19593
19594 <p><b>Proposed resolution:</b></p>
19595 <p>
19596 Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
19597 </p>
19598
19599
19600
19601
19602
19603 <hr>
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>
19612 <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>?
19615 </p>
19616
19617 <p><i>[
19618 Bellevue:
19619 ]</i></p>
19620
19621
19622 <blockquote>
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.
19627 </blockquote>
19628
19629 <p><i>[
19630 2009-07 Frankfurt:
19631 ]</i></p>
19632
19633
19634 <blockquote>
19635 Duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a> (for our purposes).
19636 </blockquote>
19637
19638 <p><i>[
19639 Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
19640 ]</i></p>
19641
19642
19643
19644
19645 <p><b>Proposed resolution:</b></p>
19646
19647
19648
19649
19650
19651
19652 <hr>
19653 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</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>
19659 <p>
19660 A number of vector&lt;bool&gt; members take const bool&amp; 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?
19663 </p>
19664
19665 <p><i>[
19666 post Bellevue:
19667 ]</i></p>
19668
19669
19670 <blockquote>
19671 <p>
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.
19676 </p>
19677 <p>
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.
19680 </p>
19681 <p>
19682 Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
19683 and that at this point in the process it's not worth the bandwidth.
19684 </p>
19685 <p>
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.
19688 </p>
19689 <p>
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
19693 as-if rule.
19694 </p>
19695 </blockquote>
19696
19697 <p><i>[
19698 San Francisco:
19699 ]</i></p>
19700
19701
19702 <blockquote>
19703 <p>
19704 This is really a clause 17 issue, rather than something specific to vector&lt;bool&gt;.
19705 </p>
19706 <p>
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&lt;bool&gt; one).
19710 </p>
19711 <p>
19712 Howard:  Haven't yet opened new issue.  Lacking wording for it.
19713 </p>
19714 </blockquote>
19715
19716 <p><i>[
19717 2009-07 Frankfurt:
19718 ]</i></p>
19719
19720
19721 <blockquote>
19722 NAD.  Insufficient motivation to make any changes.
19723 </blockquote>
19724
19725
19726 <p><b>Proposed resolution:</b></p>
19727 <p>
19728 </p>
19729
19730
19731
19732
19733
19734 <hr>
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>
19741 <p>
19742 14882-2003, [lib.uninitialized.copy] is currently written as follows:
19743 </p>
19744
19745 <blockquote>
19746 <pre>template &lt;class InputIterator, class ForwardIterator&gt;
19747   ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
19748                                      ForwardIterator <i>result</i>);
19749 </pre>
19750 <blockquote>
19751 <p>
19752 -1- <i>Effects:</i>
19753 </p>
19754 <blockquote><pre>for (; first != last; ++result, ++first)
19755   new (static_cast&lt;void*&gt;(&amp;*result))
19756     typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
19757 </pre></blockquote>
19758 <p>
19759 -2- <i>Returns:</i> <tt><i>result</i></tt>
19760 </p>
19761 </blockquote>
19762 </blockquote>
19763
19764 <p>
19765 similarily for N2369, and its corresponding section
19766 20.9.8.2 [uninitialized.copy].
19767 </p>
19768
19769 <p>
19770 It's not clear to me what the return clause is supposed to mean, I see
19771 two
19772 possible interpretations:
19773 </p>
19774
19775 <ol type="a">
19776 <li>
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
19781 parameter
19782 and the name used in the clause do have the same italic font.
19783 </li>
19784 <li>
19785 The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
19786 after the
19787 preceding effects clause. This is in fact what all implementations I
19788 checked
19789 do (and which is probably it's intend, because it matches the
19790 specification of <tt>std::copy</tt>).
19791 </li>
19792 </ol>
19793
19794 <p>
19795 The problem is: I see nothing in the standard which grants that this
19796 interpretation
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
19800 the elements
19801 of the detailed specifications - Do they relate to the corresponding
19802 synopsis or
19803 to the effects clause (or possibly other elements)? Fortunately most
19804 detailed
19805 descriptions are unambigious in this regard, e.g. this problem does
19806 not apply
19807 for <tt>std::copy</tt>.
19808 </p>
19809
19810
19811
19812 <p><b>Proposed resolution:</b></p>
19813 <p>
19814 Change the wording of the return clause to say (20.9.8.2 [uninitialized.copy]):
19815 </p>
19816
19817 <blockquote>
19818 <p>
19819 -2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
19820 </p>
19821 </blockquote>
19822
19823
19824 <p><i>[
19825 Bellevue:
19826 ]</i></p>
19827
19828
19829 <blockquote>
19830 Resolution: NAD editorial -- project editor to decide if change is
19831 worthwhile. Concern is that there are many other places this might
19832 occur.
19833 </blockquote>
19834
19835
19836
19837
19838 <hr>
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>
19845 <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:
19853 </p>
19854
19855 <blockquote><pre>template&lt;typename... _Args&gt;
19856 void
19857 push(_Args&amp;&amp;... __args)
19858   { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
19859 </pre></blockquote>
19860
19861 <p><i>[
19862 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19863 ]</i></p>
19864
19865
19866
19867 <p><b>Proposed resolution:</b></p>
19868 <p>
19869 Change 23.5.1.1 [queue.defn]:
19870 </p>
19871
19872 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19873 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19874 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19875 </pre></blockquote>
19876
19877 <p>
19878 Change 23.5.2 [priority.queue]:
19879 </p>
19880
19881 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19882 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19883 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19884 </pre></blockquote>
19885
19886 <p>
19887 Change 23.5.2.3 [priqueue.members]:
19888 </p>
19889
19890 <blockquote>
19891 <pre><del>void push(const value_type&amp; x);</del>
19892 </pre>
19893 <blockquote>
19894 <p>
19895 <del><i>Effects:</i></del>
19896 </p>
19897 <blockquote><pre><del>c.push_back(x);</del>
19898 <del>push_heap(c.begin(), c.end(), comp);</del>
19899 </pre></blockquote>
19900 </blockquote>
19901
19902 <pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
19903 </pre>
19904 <blockquote>
19905 <p>
19906 <i>Effects:</i>
19907 </p>
19908 <blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
19909 push_heap(c.begin(), c.end(), comp);
19910 </pre></blockquote>
19911 </blockquote>
19912 </blockquote>
19913
19914 <p>
19915 Change 23.5.3.1 [stack.defn]:
19916 </p>
19917
19918 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19919 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19920 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19921 </pre></blockquote>
19922
19923
19924
19925 <p><b>Rationale:</b></p>
19926 <p>
19927 Addressed by
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>.
19929 </p>
19930
19931
19932
19933
19934
19935 <hr>
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>
19942 <p>
19943 In the synopsis 23.4.1 [vector], there is the signature:
19944 </p>
19945
19946 <blockquote><pre>void insert(const_iterator position, size_type n, T&amp;&amp; x);
19947 </pre></blockquote>
19948
19949 <p>
19950 instead of:
19951 </p>
19952
19953 <blockquote><pre>iterator insert(const_iterator position, T&amp;&amp; x);
19954 </pre></blockquote>
19955
19956 <p>
19957 23.4.1.4 [vector.modifiers] is fine.
19958 </p>
19959
19960
19961
19962 <p><b>Proposed resolution:</b></p>
19963 <p>
19964 Change the synopsis in 23.4.1 [vector]:
19965 </p>
19966
19967 <blockquote><pre>iterator insert(const_iterator position, const T&amp; x); 
19968 <ins>iterator insert(const_iterator position, T&amp;&amp; x);</ins>
19969 void     insert(const_iterator position, size_type n, const T&amp; x); 
19970 <del>void     insert(const_iterator position, size_type n, T&amp;&amp; x);</del>
19971 </pre></blockquote>
19972
19973
19974
19975
19976
19977 <hr>
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>
19984 <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
19993 implemented anyway
19994 </p>
19995
19996 <p><i>[
19997 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19998 ]</i></p>
19999
20000
20001 <p><i>[
20002 Bellevue:
20003 ]</i></p>
20004
20005
20006 <blockquote>
20007 <p>
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?
20011 </p>
20012 <p>
20013 Resolution: Alan Talbot to rework language, then set state to Review.
20014 </p>
20015 </blockquote>
20016
20017 <p><i>[
20018 2009-07 Frankfurt
20019 ]</i></p>
20020
20021
20022 <blockquote>
20023 <p>
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.
20027 </p>
20028 <p>
20029 NAD Future.
20030 </p>
20031 </blockquote>
20032
20033
20034
20035 <p><b>Proposed resolution:</b></p>
20036 <p>
20037 Add after 23.2 [container.requirements]/12:
20038 </p>
20039
20040 <blockquote>
20041 <p>
20042 -12- Objects passed to member functions of a container as rvalue
20043 references shall not be elements of that container. No diagnostic
20044 required.
20045 </p>
20046 <p>
20047 <ins>
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.
20051 </ins>
20052 </p>
20053
20054 </blockquote>
20055
20056
20057
20058
20059
20060
20061 <hr>
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>
20069 <p>
20070 The associative containers provide 2 overloads of <tt>emplace()</tt>:
20071 </p>
20072
20073 <blockquote><pre>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace(Args&amp;&amp;... args);
20074 template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
20075 </pre></blockquote>
20076
20077 <p>
20078 This is a problem if you mean the first overload while passing
20079 a <tt>const_iterator</tt> as first argument.
20080 </p>
20081
20082 <p><i>[
20083 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
20084 ]</i></p>
20085
20086
20087 <p><i>[
20088 Bellevue:
20089 ]</i></p>
20090
20091
20092 <blockquote>
20093 </blockquote>
20094 <p>
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
20097 will be rare.
20098 </p>
20099 <p>
20100 Resolution: Change state to NAD.
20101 </p>
20102
20103
20104 <p><b>Proposed resolution:</b></p>
20105 <p>
20106 Rename one of the two overloads.
20107 For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
20108 </p>
20109
20110
20111
20112
20113
20114 <hr>
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>
20122 <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>.
20129 </p>
20130 <p>
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&lt;B::iterator, B::iterator&gt;</tt>. Consider the following code:
20134 </p>
20135
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
20140 }
20141 </pre></blockquote>
20142
20143 <p>
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.
20150 </p>
20151 <p>
20152 If instead of returning <tt>pair&lt;iterator, iterator&gt;</tt>, <tt>equal_range</tt> were to 
20153 return <tt>pair&lt;local_iterator, local_iterator&gt;</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.
20159 </p>
20160
20161 <p><i>[
20162 Bellevue:
20163 ]</i></p>
20164
20165
20166 <blockquote>
20167 The proposed resolution breaks consistency with other container types
20168 for dubious benefit, and iterators are already constant time.
20169 </blockquote>
20170
20171
20172
20173 <p><b>Proposed resolution:</b></p>
20174 <p>
20175 Change the entry for <tt>equal_range</tt> in Table 93 (23.2.5 [unord.req]) as follows:
20176 </p>
20177 <table border="1">
20178 <tbody><tr>
20179 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
20180 </tr>
20181
20182 <tr>
20183 <td><tt>b.equal_range(k)</tt></td>
20184 <td><tt>pair&lt;<ins>local_</ins>iterator,<ins>local_</ins>iterator&gt;; pair&lt;const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator&gt;</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 &#920;<tt>(b.count(k))</tt>. Worst case &#920;<tt>(b.size())</tt>. </td>
20187 </tr>
20188 </tbody></table>
20189
20190
20191
20192
20193
20194 <hr>
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>
20201 <p>
20202 Playing with g++'s C++0X mode, I noticed that the following
20203 code, which used to compile:
20204 </p>
20205
20206 <blockquote><pre>#include &lt;vector&gt;
20207
20208 int main()
20209 {
20210     std::vector&lt;char *&gt; v;
20211     v.push_back(0);
20212 }
20213 </pre></blockquote>
20214
20215 <p>
20216 now fails with the following error message:
20217 </p>
20218
20219 <blockquote>
20220 .../include/c++/4.3.0/ext/new_allocator.h: In member function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*, _Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
20221 .../include/c++/4.3.0/bits/stl_vector.h:707:   instantiated from 'void std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with _Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
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*'
20224 </blockquote>
20225
20226 <p>
20227 As far as I know, g++ follows the current draft here.
20228 </p>
20229 <p>
20230 Does the committee really intend to break compatibility for such cases?
20231 </p>
20232
20233 <p><i>[
20234 Sylvain adds: 
20235 ]</i></p>
20236
20237
20238 <blockquote>
20239 <p>
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:
20242 </p>
20243
20244 <blockquote><pre>#include &lt;utility&gt;
20245
20246 int main()
20247 {
20248    std::pair&lt;char *, char *&gt; p (0,0);
20249 }
20250 </pre></blockquote>
20251
20252 <p>
20253 I have not made any general audit for such problems elsewhere.
20254 </p>
20255 </blockquote>
20256
20257 <p><i>[
20258 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
20259 ]</i></p>
20260
20261
20262 <p><i>[
20263 Bellevue:
20264 ]</i></p>
20265
20266
20267 <blockquote>
20268 <p>
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
20273 complexity.
20274 </p>
20275 <p>
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.
20280 </p>
20281 <p>
20282 Another approach is to change the member names. Yet another approach is
20283 to forbid the extension in absence of concepts.
20284 </p>
20285 <p>
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
20289 moved to NAD.
20290 </p>
20291 </blockquote>
20292
20293
20294
20295 <p><b>Proposed resolution:</b></p>
20296 <p>
20297 Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
20298 </p>
20299
20300 <blockquote>
20301 <table border="1">
20302 <tbody><tr>
20303 <th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
20304 </tr>
20305
20306 <tr>
20307 <td>
20308 <tt>a.push_front(t)</tt>
20309 </td>
20310 <td>
20311 <tt>void</tt>
20312 </td>
20313 <td>
20314 <tt>a.insert(a.begin(), t)</tt><br>
20315 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
20316 </td>
20317 <td>
20318 <tt>list, deque</tt>
20319 </td>
20320 </tr>
20321
20322 <tr>
20323 <td>
20324 <tt>a.push_front(rv)</tt>
20325 </td>
20326 <td>
20327 <tt>void</tt>
20328 </td>
20329 <td>
20330 <tt>a.insert(a.begin(), rv)</tt><br>
20331 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
20332 </td>
20333 <td>
20334 <tt>list, deque</tt>
20335 </td>
20336 </tr>
20337
20338 <tr>
20339 <td>
20340 <tt>a.push_back(t)</tt>
20341 </td>
20342 <td>
20343 <tt>void</tt>
20344 </td>
20345 <td>
20346 <tt>a.insert(a.end(), t)</tt><br>
20347 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
20348 </td>
20349 <td>
20350 <tt>list, deque, vector, basic_string</tt>
20351 </td>
20352 </tr>
20353
20354 <tr>
20355 <td>
20356 <tt>a.push_back(rv)</tt>
20357 </td>
20358 <td>
20359 <tt>void</tt>
20360 </td>
20361 <td>
20362 <tt>a.insert(a.end(), rv)</tt><br>
20363 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
20364 </td>
20365 <td>
20366 <tt>list, deque, vector, basic_string</tt>
20367 </td>
20368 </tr>
20369
20370 </tbody></table>
20371 </blockquote>
20372
20373 <p>
20374 Change the synopsis in 23.3.2 [deque]:
20375 </p>
20376
20377 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
20378 <ins>void push_front(T&amp;&amp; x);</ins>
20379 <ins>void push_back(const T&amp; x);</ins>
20380 <ins>void push_back(T&amp;&amp; x);</ins>
20381 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
20382 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20383 </pre></blockquote>
20384
20385 <p>
20386 Change 23.3.2.3 [deque.modifiers]:
20387 </p>
20388
20389 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
20390 <ins>void push_front(T&amp;&amp; x);</ins>
20391 <ins>void push_back(const T&amp; x);</ins>
20392 <ins>void push_back(T&amp;&amp; x);</ins>
20393 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
20394 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20395 </pre></blockquote>
20396
20397 <p>
20398 Change the synopsis in 23.3.4 [list]:
20399 </p>
20400
20401 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
20402 <ins>void push_front(T&amp;&amp; x);</ins>
20403 <ins>void push_back(const T&amp; x);</ins>
20404 <ins>void push_back(T&amp;&amp; x);</ins>
20405 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
20406 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20407 </pre></blockquote>
20408
20409 <p>
20410 Change 23.3.4.3 [list.modifiers]:
20411 </p>
20412
20413 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
20414 <ins>void push_front(T&amp;&amp; x);</ins>
20415 <ins>void push_back(const T&amp; x);</ins>
20416 <ins>void push_back(T&amp;&amp; x);</ins>
20417 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
20418 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20419 </pre></blockquote>
20420
20421 <p>
20422 Change the synopsis in 23.4.1 [vector]:
20423 </p>
20424
20425 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
20426 <ins>void push_back(T&amp;&amp; x);</ins>
20427 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20428 </pre></blockquote>
20429
20430 <p>
20431 Change 23.4.1.4 [vector.modifiers]:
20432 </p>
20433
20434 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
20435 <ins>void push_back(T&amp;&amp; x);</ins>
20436 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
20437 </pre></blockquote>
20438
20439
20440
20441
20442 <p><b>Rationale:</b></p>
20443 <p>
20444 Addressed by
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>.
20446 </p>
20447
20448 <p>
20449 If there is still an issue with pair, Howard should submit another issue.
20450 </p>
20451
20452
20453
20454
20455
20456 <hr>
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>
20463 <ol>
20464 <li>
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.
20469 </li>
20470
20471 <li>
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.
20475 </li>
20476
20477 <li>
20478 26.5.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
20479 </li>
20480 </ol>
20481
20482 <p><i>[
20483 Bellevue:
20484 ]</i></p>
20485
20486
20487 <blockquote>
20488 NAD. Withdrawn.
20489 </blockquote>
20490
20491
20492 <p><b>Proposed resolution:</b></p>
20493 <p>
20494 </p>
20495
20496
20497
20498
20499
20500 <hr>
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>
20506 <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.
20510 </p>
20511
20512 <p>
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).
20515 </p>
20516
20517 <p>
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.
20523 </p>
20524
20525 <p>
20526 An alternative name for release may be <tt>disown</tt>.
20527 </p>
20528
20529 <p>
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>).
20532 </p>
20533
20534 <p><i>[
20535 Bellevue:
20536 ]</i></p>
20537
20538
20539 <blockquote>
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
20543 changing. NAD
20544 </blockquote>
20545
20546
20547 <p><b>Proposed resolution:</b></p>
20548 <p>
20549 Change the synopsis in 30.4.2.2 [thread.lock.unique]:
20550 </p>
20551
20552 <blockquote><pre>template &lt;class Mutex&gt; 
20553 class unique_lock 
20554
20555 public:
20556    ...
20557    mutex_type* <del>release</del> <ins>disown</ins>();
20558    ...
20559 };
20560 </pre></blockquote>
20561
20562 <p>
20563 Change 30.4.2.2.3 [thread.lock.unique.mod]:
20564 </p>
20565
20566 <blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
20567 </pre></blockquote>
20568
20569
20570
20571
20572
20573 <hr>
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>
20579 <p>
20580 Table 16 of TR1 requires that all Pseudo Random Number generators have a
20581 </p>
20582
20583 <blockquote><pre>seed(integer-type s)
20584 </pre></blockquote>
20585
20586 <p>
20587 member function that is equivalent to:
20588 </p>
20589
20590 <blockquote><pre>mygen = Generator(s)
20591 </pre></blockquote>
20592
20593 <p>
20594 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
20595 </p>
20596
20597 <blockquote><pre>template &lt;class Gen&gt;
20598 seed(Gen&amp;);
20599 </pre></blockquote>
20600
20601 <p>
20602 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
20603 </p>
20604
20605 <p>
20606 So... is this a bug in TR1?
20607 </p>
20608
20609 <p>
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.
20611 </p>
20612
20613 <p><i>[
20614 Jens adds:
20615 ]</i></p>
20616
20617
20618 <blockquote>
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.
20622 </blockquote>
20623
20624 <p><i>[
20625 Post Summit Daniel adds:
20626 ]</i></p>
20627
20628
20629 <blockquote>
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.
20633 </blockquote>
20634
20635 <p><i>[
20636 Batavia (2009-05):
20637 ]</i></p>
20638
20639 <blockquote>
20640 Move to NAD as recommended.
20641 </blockquote>
20642
20643
20644 <p><b>Proposed resolution:</b></p>
20645 <p>
20646 NAD Recommended.
20647 </p>
20648
20649
20650
20651
20652
20653 <hr>
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>
20660 <p>
20661 <tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&amp;)</tt> don't say what
20662 happens to each of the sub-engine seeds. (Should probably do the same
20663 to both, unlike TR1.)
20664 </p>
20665
20666 <p><i>[
20667 Bellevue:
20668 ]</i></p>
20669
20670
20671 <blockquote>
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>.
20673 </blockquote>
20674
20675
20676
20677 <p><b>Proposed resolution:</b></p>
20678
20679
20680
20681
20682
20683 <hr>
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>
20690 <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
20693 by areas.)
20694 </p>
20695
20696 <p><i>[
20697 Bellevue:
20698 ]</i></p>
20699
20700
20701 <blockquote>
20702 <p>
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.
20708 </p>
20709
20710 <p>
20711 We don't think this should be changed.
20712 </p>
20713
20714 <p>
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
20720 variates.
20721 </p>
20722 </blockquote>
20723
20724
20725
20726 <p><b>Proposed resolution:</b></p>
20727
20728 <p>
20729 Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]:
20730 </p>
20731
20732 <blockquote><pre>template &lt;class RealType = double&gt; 
20733 class piecewise_constant_distribution 
20734
20735 public:
20736     ...
20737     vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
20738     ...
20739 };
20740 </pre></blockquote>
20741
20742 <p>
20743 Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
20744 </p>
20745
20746 <blockquote><pre>vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
20747 </pre></blockquote>
20748
20749
20750
20751
20752
20753
20754 <hr>
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>
20761 <p>
20762 <tt>discrete_distribution</tt> should have a constructor like:
20763 </p>
20764
20765 <blockquote><pre>template&lt;class _Fn&gt;
20766   discrete_distribution(result_type _Count, double _Low, double _High,
20767                         _Fn&amp; _Func);
20768 </pre></blockquote>
20769
20770 <p>
20771 (Makes it easier to fill a histogram with function values over a range.)
20772 </p>
20773
20774 <p><i>[
20775 Bellevue:
20776 ]</i></p>
20777
20778
20779 <blockquote>
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.
20784 </blockquote>
20785
20786 <p><i>[
20787 Sophia Antipolis:
20788 ]</i></p>
20789
20790
20791 <blockquote>
20792 <p>
20793 Bill is not requesting this.
20794 </p>
20795 <p>
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.
20799 </p>
20800 <p>
20801 Jens: lambda expressions are rvalues
20802 </p>
20803 <p>
20804 Add a library issue to provide an
20805 <tt>initializer_list&lt;double&gt;</tt> constructor for
20806 <tt>discrete_distribution</tt>.
20807 </p>
20808 <p>
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.
20811 </p>
20812 <p>
20813 Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
20814 </p>
20815 <p>
20816 Daniel to draft wording.
20817 </p>
20818 </blockquote>
20819
20820 <p><i>[
20821 Pre San Francisco, Daniel provided wording:
20822 ]</i></p>
20823
20824
20825 <blockquote>
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&amp;&amp;</tt> in this proposal as part
20835 of an editorial process.
20836 </blockquote>
20837
20838
20839
20840 <p><b>Proposed resolution:</b></p>
20841
20842 <p><b>Non-concept version of the proposed resolution</b></p>
20843
20844 <ol>
20845 <li>
20846 <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
20849 </p>
20850
20851 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
20852 </pre></blockquote>
20853
20854 <p>
20855 insert:
20856 </p>
20857
20858
20859 <blockquote><pre>template&lt;typename Func&gt;
20860 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20861 </pre></blockquote>
20862 </li>
20863
20864 <li>
20865 <p>
20866 Between p.4 and p.5 insert a series of new paragraphs as part of the
20867 new member description::
20868 </p>
20869 <blockquote><pre>template&lt;typename Func&gt;
20870 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20871 </pre>
20872
20873 <p>
20874 <i>Complexity:</i> Exactly nf invocations of fw.
20875 </p>
20876 <p>
20877 <i>Requires:</i>
20878 </p>
20879 <ol type="a">
20880 <li>
20881 fw shall be callable with one argument of type double, and shall
20882 return values of a type convertible to double;</li>
20883
20884 <li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <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>
20887
20888 <li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20889
20890 </ol>
20891
20892 <p>
20893 <i>Effects:</i>
20894 </p>
20895 <ol type="a">
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>
20898
20899 <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> +
20901 0.5 * deltax.</p>
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>
20906 </li>
20907 <li>
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>
20911 </li>
20912 </ol>
20913 </blockquote>
20914 </li>
20915 </ol>
20916
20917 <p><b>Concept version of the proposed resolution</b></p>
20918
20919
20920 <ol>
20921 <li>
20922 <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
20925 </p>
20926
20927 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
20928 </pre></blockquote>
20929
20930 <p>
20931 insert:
20932 </p>
20933
20934
20935 <blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
20936  requires Convertible&lt;Func::result_type, double&gt;
20937 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20938 </pre></blockquote>
20939 </li>
20940
20941 <li>
20942 <p>
20943 Between p.4 and p.5 insert a series of new paragraphs as part of the
20944 new member description::
20945 </p>
20946 <blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
20947  requires Convertible&lt;Func::result_type, double&gt;
20948 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20949 </pre>
20950
20951 <p>
20952 <i>Complexity:</i> Exactly nf invocations of fw.
20953 </p>
20954 <p>
20955 <i>Requires:</i>
20956 </p>
20957 <ol type="a">
20958 <li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <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>
20961
20962 <li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20963
20964 </ol>
20965
20966 <p>
20967 <i>Effects:</i>
20968 </p>
20969 <ol type="a">
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>
20972
20973 <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> +
20975 0.5 * deltax.</p>
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>
20980 </li>
20981 <li>
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>
20985 </li>
20986 </ol>
20987 </blockquote>
20988 </li>
20989 </ol>
20990
20991
20992
20993 <p><b>Rationale:</b></p>
20994 Addressed by
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".
20996
20997
20998
20999
21000
21001 <hr>
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>
21008 <p>
21009 <tt>piecewise_constant_distribution</tt> should have a constructor like:
21010 </p>
21011
21012 <blockquote><pre>template&lt;class _Fn&gt;
21013    piecewise_constant_distribution(size_t _Count,
21014             _Ty _Low, _Ty _High, _Fn&amp; _Func);
21015 </pre></blockquote>
21016
21017 <p>
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>.)
21021 </p>
21022
21023 <p><i>[
21024 Sophia Antipolis:
21025 ]</i></p>
21026
21027
21028 <blockquote>
21029 <p>
21030 Marc: uses variable width of bins and weight for each bin. This is not
21031 giving enough flexibility to control both variables.
21032 </p>
21033 <p>
21034 Add a library issue to provide an constructor taking an
21035 <tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
21036 </p>
21037 <p>
21038 Daniel to draft wording.
21039 </p>
21040 </blockquote>
21041
21042 <p><i>[
21043 Pre San Francisco, Daniel provided wording.
21044 ]</i></p>
21045
21046
21047 <blockquote>
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.
21056 </blockquote>
21057
21058
21059
21060 <p><b>Proposed resolution:</b></p>
21061
21062 <p><b>Non-concept version of the proposed resolution</b></p>
21063
21064 <ol>
21065 <li>
21066 <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
21069 </p>
21070
21071 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
21072 </pre></blockquote>
21073 <p>
21074 insert:
21075 </p>
21076 <blockquote><pre>template&lt;typename Func&gt;
21077 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21078 </pre></blockquote>
21079 </li>
21080
21081 <li>
21082 <p>
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:
21086 </p>
21087
21088 <blockquote><pre>template&lt;typename Func&gt;
21089 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21090 </pre>
21091 <blockquote>
21092 <p>
21093 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
21094 </p>
21095 <p>
21096 [p5_2] <i>Requires:</i>
21097 </p>
21098 <ol type="a">
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;
21101 </li>
21102 <li>
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;
21105 </li>
21106 <li>
21107 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
21108 0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
21109 </li>
21110 </ol>
21111 <p>
21112 [p5_3] <i>Effects:</i>
21113 </p>
21114 <ol type="a">
21115 <li>
21116 <p>If nf == 0,</p>
21117  <ol type="a">
21118  <li>
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>
21124 </li>
21125 </ol>
21126 </li>
21127 <li>
21128 <p>Otherwise,</p>
21129 <ol type="a">
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
21132 </li>
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> 
21140 <p> and</p>
21141 </li>
21142 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
21143 </ol>
21144 </li>
21145 <li>
21146 <p>
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:
21150 </p>
21151 <blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
21152 </pre></blockquote> 
21153 </li>
21154 </ol>
21155 <p>
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>]
21158  </p>
21159 </blockquote>
21160 </blockquote>
21161 </li>
21162 </ol>
21163
21164 <p><b>Concept version of the proposed resolution</b></p>
21165
21166 <ol>
21167 <li>
21168 <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
21171 </p>
21172
21173 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
21174 </pre></blockquote>
21175 <p>
21176 insert:
21177 </p>
21178 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
21179  requires Convertible&lt;Func::result_type, double&gt;
21180 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21181 </pre></blockquote>
21182 </li>
21183
21184 <li>
21185 <p>
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:
21189 </p>
21190
21191 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
21192  requires Convertible&lt;Func::result_type, double&gt;
21193 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
21194 </pre>
21195 <blockquote>
21196 <p>
21197 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
21198 </p>
21199 <p>
21200 [p5_2] <i>Requires:</i>
21201 </p>
21202 <ol type="a">
21203 <li>
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;
21206 </li>
21207 <li>
21208 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
21209 0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
21210 </li>
21211 </ol>
21212 <p>
21213 [p5_3] <i>Effects:</i>
21214 </p>
21215 <ol type="a">
21216 <li>
21217 <p>If nf == 0,</p>
21218  <ol type="a">
21219  <li>
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>
21225 </li>
21226 </ol>
21227 </li>
21228 <li>
21229 <p>Otherwise,</p>
21230 <ol type="a">
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
21233 </li>
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> 
21241 <p> and</p>
21242 </li>
21243 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
21244 </ol>
21245 </li>
21246 <li>
21247 <p>
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:
21251 </p>
21252 <blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
21253 </pre></blockquote> 
21254 </li>
21255 </ol>
21256 <p>
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>]
21259  </p>
21260 </blockquote>
21261 </blockquote>
21262 </li>
21263 </ol>
21264
21265
21266
21267 <p><b>Rationale:</b></p>
21268 Addressed by
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".
21270
21271
21272
21273
21274
21275 <hr>
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>
21283 <p>
21284 <tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
21285 adaptive numerical integration.)
21286 </p>
21287
21288 <p><i>[
21289 Stephan Tolksdorf notes:
21290 ]</i></p>
21291
21292
21293 <blockquote>
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>.
21295 </blockquote>
21296
21297
21298 <p><b>Proposed resolution:</b></p>
21299
21300
21301
21302
21303
21304
21305 <hr>
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>
21312 <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.)
21316 </p>
21317
21318 <p><i>[
21319 Bellevue:
21320 ]</i></p>
21321
21322
21323 <blockquote>
21324 Submitter withdraws defect.
21325 </blockquote>
21326
21327
21328
21329 <p><b>Proposed resolution:</b></p>
21330 <p>
21331 Change 26.5.5 [rand.predef]/p5:
21332 </p>
21333
21334 <blockquote>
21335 <pre>typedef subtract_with_carry_engine&lt;uint_fast64_t, 48, 5, 12&gt; 
21336         ranlux48_base; 
21337 </pre>
21338 <blockquote>
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>.
21342 </blockquote>
21343 </blockquote>
21344
21345
21346
21347
21348
21349 <hr>
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>
21356 <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>.)
21360 </p>
21361 <p><i>[
21362 Bellevue:
21363 ]</i></p>
21364
21365
21366 <blockquote>
21367 Submitter withdraws defect.
21368 </blockquote>
21369
21370
21371
21372 <p><b>Proposed resolution:</b></p>
21373 <p>
21374 Change 26.5.5 [rand.predef]/p6:
21375 </p>
21376
21377 <blockquote>
21378 <pre>typedef discard_block_engine&lt;ranlux48_base, 389, 11&gt; 
21379         ranlux48
21380 </pre>
21381 <blockquote>
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>.
21385 </blockquote>
21386 </blockquote>
21387
21388
21389
21390
21391
21392 <hr>
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>
21399 <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.
21408 </p>
21409
21410 <p>
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.
21421 </p>
21422
21423 <p>
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
21429 something similar.
21430 </p>
21431
21432 <p>
21433 These changes would likely have no practical effect, but would allow an
21434 implementation that does the right thing to be standard-conformant.
21435 </p>
21436
21437 <p><i>[
21438 Bellevue:
21439 ]</i></p>
21440
21441
21442 <blockquote>
21443 <p>
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
21446 to REVIEW.
21447 </p>
21448 <p>
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!
21455 </p>
21456 <p>
21457 Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
21458 </p>
21459 </blockquote>
21460
21461
21462 <p><b>Proposed resolution:</b></p>
21463 <p>
21464 In 26.5.3.2 [rand.eng.mers]:
21465 </p>
21466
21467 <blockquote>
21468 <p>
21469 Insert at the end of para 2.:
21470 </p>
21471
21472 <blockquote>
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>]
21476 </blockquote>
21477
21478 <p>
21479 In para 5. change:
21480 </p>
21481
21482 <blockquote>
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.
21486 </blockquote>
21487 </blockquote>
21488
21489
21490
21491
21492
21493 <hr>
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>
21500 <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>
21508 to 0.
21509 </p>
21510
21511 <p>
21512 There are two more minor issues:
21513 </p>
21514
21515 <ul>
21516 <li>
21517 Strictly speaking <tt>end - begin</tt> is not defined since
21518 <tt>InputIterator</tt> is not required to be a random access iterator.
21519 </li>
21520 <li>
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.
21525 </li>
21526 </ul>
21527
21528 <p><i>[
21529 Bellevue:
21530 ]</i></p>
21531
21532
21533 <blockquote>
21534 Move to OPEN Bill will try to propose a resolution by the next meeting.
21535 </blockquote>
21536
21537 <p><i>[
21538 post Bellevue:  Bill provided wording.
21539 ]</i></p>
21540
21541
21542 <p>
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.
21544 </p>
21545
21546
21547
21548 <p><b>Proposed resolution:</b></p>
21549 <p>
21550 Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
21551 </p>
21552
21553 <blockquote>
21554 <p>
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,
21557 end)</tt>
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
21560 following
21561 algorithm:
21562 </p>
21563
21564 <blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
21565    v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
21566 </pre></blockquote>
21567 </blockquote>
21568
21569
21570 <p><b>Rationale:</b></p>
21571 Addressed by
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".
21573
21574
21575
21576
21577
21578 <hr>
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>
21585 <p>
21586 The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
21587 1112339016. We get 2126698284.
21588 </p>
21589
21590
21591 <p><b>Proposed resolution:</b></p>
21592 <p>
21593 Change 26.5.5 [rand.predef]/p8:
21594 </p>
21595
21596 <blockquote>
21597 <pre>typedef shuffle_order_engine&lt;minstd_rand0, 256&gt; 
21598         knuth_b; 
21599 </pre>
21600 <blockquote>
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>.
21604 </blockquote>
21605 </blockquote>
21606
21607
21608 <p><i>[
21609 Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
21610 ]</i></p>
21611
21612
21613
21614
21615
21616 <hr>
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>
21623 <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
21626 32-bit vector.
21627 </p>
21628 <p>
21629 This repacking triggers several problems:
21630 </p>
21631 <ol>
21632 <li>
21633 Distinctness of the output of <tt>seed_seq::generate</tt> required the
21634 introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
21635 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
21636 </li>
21637 <li>
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.)
21641 </li>
21642 <li>
21643 The description and algorithm have become unduly complicated.
21644 </li>
21645 </ol>
21646 <p>
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
21649 below).
21650 </p>
21651 <p>
21652 Here's how the description would read
21653 </p>
21654 <blockquote>
21655 <p>
21656 26.5.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
21657 </p>
21658
21659 <blockquote>
21660 <pre>template&lt;class InputIterator&gt;
21661   seed_seq(InputIterator begin, InputIterator end);
21662 </pre>
21663 <blockquote>
21664 <p>
21665 5 <i>Requires:</i> NO CHANGE
21666 </p>
21667 <p>
21668 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
21669 </p>
21670 <blockquote>
21671 <pre>for (InputIterator s = begin; s != end; ++s)
21672    v.push_back((*s) mod 2^32);
21673 </pre>
21674 </blockquote>
21675 </blockquote>
21676 </blockquote>
21677 </blockquote>
21678
21679 <p>
21680 Discussion:
21681 </p>
21682 <p>
21683 The chief virtues here are simplicity, portability, and generality.
21684 </p>
21685 <ul>
21686 <li>
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.
21689 </li>
21690 <li>
21691 Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
21692 uint_least32_t</tt> the user is guaranteed to get the same behavior across
21693 platforms.
21694 </li>
21695 <li>
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).
21701 </li>
21702 </ul>
21703 <p>
21704 Arguments (and counter-arguments) against making this change (and
21705 retaining the
21706 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21707 behavior) are:
21708 </p>
21709 <ul>
21710 <li>
21711 <p>
21712 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
21713  repack it.
21714 </p>
21715 <p>
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
21719 </p>
21720 <blockquote><pre>v = { 0x3, 0x434241 };
21721 </pre></blockquote>
21722 <p>
21723 while the simplified proposal yields
21724 </p>
21725 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
21726 </pre></blockquote>
21727 <p>
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.
21731 </p>
21732 </li>
21733 <li>
21734 <p>
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.
21738 </p>
21739 <p>
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>.
21743 </p>
21744 </li>
21745 <li>
21746 <p>
21747 A user can pass an array of 64-bit integers and all the bits will be
21748  used.
21749 </p>
21750 <p>
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>
21758  proposal with
21759 </p>
21760 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
21761 seed_seq q(s, s+4);
21762 </pre></blockquote>
21763 <p>
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.
21767 </p>
21768 </li>
21769 </ul>
21770
21771 <p>
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>.
21773 </p>
21774
21775 <p><i>[
21776 Bellevue:
21777 ]</i></p>
21778
21779
21780 <blockquote>
21781 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
21782 </blockquote>
21783
21784 <p><i>[
21785 Sophia Antipolis:
21786 ]</i></p>
21787
21788
21789 <blockquote>
21790 <p>
21791 Marc Paterno wants portable behavior between 32bit and 64bit machines;
21792 we've gone to significant trouble to support portability of engines and
21793 their values.
21794 </p>
21795 <p>
21796 Jens: the new algorithm looks perfectly portable
21797 </p>
21798 <p>
21799 Marc Paterno to review off-line.
21800 </p>
21801 <p>
21802 Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
21803 </p>
21804 <p>
21805 Disposition: move to review; unanimous consent.
21806 </p>
21807 <p>
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>)
21809 </p>
21810 </blockquote>
21811
21812
21813
21814 <p><b>Proposed resolution:</b></p>
21815 <p>
21816 Change 26.5.7.1 [rand.util.seedseq]:
21817 </p>
21818
21819 <blockquote>
21820 <pre>template&lt;class InputIterator<del>, 
21821   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
21822   seed_seq(InputIterator begin, InputIterator end);
21823 </pre>
21824 <blockquote>
21825 <p>
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&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
21828 </p>
21829 <p>
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>
21832 </p>
21833 <p>
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 = &#8721;<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>
21841 </p>
21842 <blockquote><pre><del>
21843 v.clear(); 
21844 if ($w$ &lt; 32) 
21845   v.push_back($n$); 
21846 for( ; $n$ &gt; 0; --$n$) 
21847   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
21848 </del></pre></blockquote>
21849 <blockquote>
21850 <pre><ins>
21851 for (InputIterator s = begin; s != end; ++s)
21852    v.push_back((*s) mod 2<sup>32</sup>);
21853 </ins></pre>
21854 </blockquote>
21855 </blockquote>
21856 </blockquote>
21857
21858
21859 <p><b>Rationale:</b></p>
21860 Addressed by
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".
21862
21863
21864
21865
21866
21867 <hr>
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>
21873 <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.
21882 </p>
21883 <p>
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
21887 asked for it.
21888 </p>
21889
21890 <p><i>[
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).
21894 ]</i></p>
21895
21896
21897
21898 <p><b>Proposed resolution:</b></p>
21899 <p>
21900 </p>
21901
21902
21903 <p><b>Rationale:</b></p>
21904 This is already covered by 17.6.5.6/20 in N2723.
21905
21906
21907
21908
21909
21910 <hr>
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>
21917 <p>
21918 I just noticed that the following program is legal in C++03, but
21919 is forbidden in the current draft:
21920 </p>
21921
21922 <blockquote><pre>#include &lt;vector&gt;
21923 #include &lt;iostream&gt;
21924
21925 class Toto
21926 {
21927 public:
21928     Toto() {}
21929     explicit Toto( Toto const&amp; ) {}
21930 } ;
21931
21932 int
21933 main()
21934 {
21935     std::vector&lt; Toto &gt; v( 10 ) ;
21936     return 0 ;
21937 }
21938 </pre></blockquote>
21939
21940 <p>
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.)
21944 </p>
21945
21946 <p><i>[
21947 San Francisco:
21948 ]</i></p>
21949
21950
21951 <blockquote>
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).
21954 </blockquote>
21955
21956 <p><i>[
21957 Post Summit:
21958 ]</i></p>
21959
21960
21961 <blockquote>
21962 <p>
21963 Alisdair: Proposed resolution kinda funky as these tables no longer
21964 exist. Move from direct init to copy init. Clarify with Doug, recommends
21965 NAD.
21966 </p>
21967 <p>
21968 Walter: Suggest NAD via introduction of concepts.
21969 </p>
21970 <p>
21971 Recommend close as NAD.
21972 </p>
21973 </blockquote>
21974
21975 <p><i>[
21976 2009-07 Frankfurt:
21977 ]</i></p>
21978
21979
21980 <blockquote>
21981 Need to look at again without concepts.
21982 </blockquote>
21983
21984 <p><i>[
21985 2009-07 Frankfurt:
21986 ]</i></p>
21987
21988
21989 <blockquote>
21990 <p>
21991 Move to Ready with original proposed resolution.
21992 </p>
21993 <p><i>[Howard:  Original proposed resolution restored.]</i></p>
21994
21995 </blockquote>
21996
21997 <p><i>[
21998 2010-11 Batavia:
21999 ]</i></p>
22000
22001 <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.
22007 </p>
22008
22009 <blockquote>
22010 <p>
22011 In 20.2.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
22012 </p>
22013
22014 <blockquote>
22015 <table border="1">
22016 <tbody><tr>
22017 <th>expression</th><th>post-condition</th>
22018 </tr>
22019 <tr>
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>
22021 </tr>
22022 <tr>
22023 <td colspan="2" align="center">...</td>
22024 </tr>
22025 </tbody></table>
22026 </blockquote>
22027
22028 <p>
22029 In 20.2.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
22030 </p>
22031
22032 <blockquote>
22033 <table border="1">
22034 <tbody><tr>
22035 <th>expression</th><th>post-condition</th>
22036 </tr>
22037 <tr>
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>
22039 </tr>
22040 <tr>
22041 <td colspan="2" align="center">...</td>
22042 </tr>
22043 </tbody></table>
22044 </blockquote>
22045
22046 </blockquote>
22047
22048
22049
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>.
22052
22053
22054
22055
22056
22057 <hr>
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>
22064
22065 <p>
22066 Should the following use rvalues references to stream in insert/extract
22067 operators?
22068 </p>
22069
22070 <ul>
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>
22080 </ul>
22081
22082 <p><i>[
22083 Sophia Antipolis
22084 ]</i></p>
22085
22086
22087 <blockquote>
22088 Agree with the idea in the issue, Alisdair to provide wording.
22089 </blockquote>
22090
22091 <p><i>[
22092 Daniel adds 2009-02-14:
22093 ]</i></p>
22094
22095
22096 <blockquote>
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.
22100 </blockquote>
22101
22102 <p><i>[
22103 Batavia (2009-05):
22104 ]</i></p>
22105
22106 <blockquote>
22107 <p>
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&lt;&lt;</tt> and <tt>operator&gt;&gt;</tt>
22113 that adapt rvalue streams.
22114 </p>
22115 <p>
22116 We therefore agree with Daniel's observation.
22117 Move to NAD Editorial.
22118 </p>
22119 </blockquote>
22120
22121
22122 <p><b>Proposed resolution:</b></p>
22123 <p>
22124 </p>
22125
22126
22127
22128
22129
22130 <hr>
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>
22136 <p>
22137 In the spirit of <tt>printf vs iostream</tt>...
22138 </p>
22139
22140 <p>
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?
22146 </p>
22147
22148 <p><i>[
22149 Pablo Halpern:
22150 ]</i></p>
22151
22152
22153 <blockquote>
22154 I'm not sure it constitutes a defect, but I would be in favor of adding
22155 another flag (and corresponding manipulator).
22156 </blockquote>
22157
22158 <p><i>[
22159 Martin Sebor:
22160 ]</i></p>
22161
22162
22163 <blockquote>
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>).
22169 </blockquote>
22170
22171 <p><i>[
22172 Sophia Antipolis:
22173 ]</i></p>
22174
22175
22176 <blockquote>
22177 This is not a part of C99. LWG suggests submitting a paper may be appropriate.
22178 </blockquote>
22179
22180
22181
22182 <p><b>Proposed resolution:</b></p>
22183 <p>
22184 </p>
22185
22186
22187
22188
22189
22190 <hr>
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>
22197 <p>
22198 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
22199 </p>
22200 <p>
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.
22206 </p>
22207
22208 <p><i>[
22209 Sophia Antipolis:
22210 ]</i></p>
22211
22212
22213 <blockquote>
22214 <p>
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.
22221 </p>
22222 <p>
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.
22227 </p>
22228 </blockquote>
22229
22230 <p><i>[
22231 Post Summit:
22232 ]</i></p>
22233
22234
22235 <blockquote>
22236 <p>
22237 Jens: constant initialization seems to be ok core-language wise
22238 </p>
22239 <p>
22240 Consensus: Defer to threading experts, in particular a Microsoft platform expert.
22241 </p>
22242 <p>
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.
22246 </p>
22247 <p>
22248 Lawrence: What about header file shared with C? The initialization
22249 syntax is different in C and C++.
22250 </p>
22251 <p>
22252 Recommend Keep in Review
22253 </p>
22254 </blockquote>
22255
22256 <p><i>[
22257 Batavia (2009-05):
22258 ]</i></p>
22259
22260 <blockquote>
22261 Keep in Review status pending feedback from members of the Concurrency subgroup.
22262 </blockquote>
22263
22264 <p><i>[
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>.
22266 ]</i></p>
22267
22268
22269 <p><i>[
22270 2009-10 Santa Cruz:
22271 ]</i></p>
22272
22273
22274 <blockquote>
22275 NAD Editorial.  Solved by
22276 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
22277 </blockquote>
22278
22279
22280
22281 <p><b>Proposed resolution:</b></p>
22282 <p>
22283 Change 30.4.1.2.1 [thread.mutex.class]:
22284 </p>
22285
22286 <blockquote><pre>class mutex {
22287 public:
22288   <ins>constexpr</ins> mutex();
22289   ...
22290 </pre></blockquote>
22291
22292
22293
22294
22295
22296 <hr>
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>
22303 <p>
22304   Paragraph 4 of 21.2 [char.traits] mentions that this
22305   section specifies two specializations (<code>char_traits&lt;char&gt;</code>
22306   and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
22307   four specializations provided, i.e. in addition to the two above also
22308   <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
22309   I guess this was just an oversight and there is nothing wrong with just
22310   fixing this.
22311 </p>
22312
22313 <p><i>[
22314 Alisdair adds:
22315 ]</i></p>
22316
22317 <blockquote>
22318 <tt>char_traits&lt; char16/32_t &gt;</tt>
22319 should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.3 [iostream.forward], and all the specializations
22320 taking a <tt>char_traits</tt> parameter in that header.
22321 </blockquote>
22322
22323 <p><i>[
22324 Sophia Antipolis:
22325 ]</i></p>
22326
22327
22328 <blockquote>
22329 <p>
22330 Idea of the issue is ok.
22331 </p>
22332 <p>
22333 Alisdair to provide wording, once that wording arrives, move to review.
22334 </p>
22335
22336 </blockquote>
22337
22338 <p><i>[
22339 2009-05-04 Alisdair adds:
22340 ]</i></p>
22341
22342
22343 <blockquote>
22344 <p>
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>,
22347 so we are
22348 close to NAD Editorial.
22349 However, exploring the issue we found a second tweak was necessary for
22350 <tt>&lt;iosfwd&gt;</tt> and that is still outstanding, so here are the words I am long
22351 overdue delivering:
22352 </p>
22353
22354 <p><i>[
22355 Howard:  I've put Alisdair's words into the proposed wording section and
22356 moved the issue to Review.
22357 ]</i></p>
22358
22359
22360 </blockquote>
22361
22362 <p><i>[
22363 Original proposed wording.
22364 ]</i></p>
22365
22366
22367 <blockquote>
22368
22369 <p>
22370   Replace paragraph 4 of 21.2 [char.traits] by:
22371 </p>
22372 <blockquote>
22373 <p>
22374   This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
22375   and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
22376   <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
22377   <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
22378   &lt;string&gt; and satisfy the requirements below.
22379 </p>
22380 </blockquote>
22381 </blockquote>
22382
22383 <p><i>[
22384 Batavia (2009-05):
22385 ]</i></p>
22386
22387 <blockquote>
22388 We agree.  Move to NAD Editorial.
22389 </blockquote>
22390
22391
22392 <p><b>Proposed resolution:</b></p>
22393 <p>
22394 Change Forward declarations 27.3 [iostream.forward]:
22395 </p>
22396
22397 <blockquote>
22398 <p>
22399 <b>Header <tt>&lt;iosfwd&gt;</tt> synopsis</b>
22400 </p>
22401 <pre>namespace std {
22402    template&lt;class charT&gt; class char_traits;
22403    template&lt;&gt; class char_traits&lt;char&gt;;
22404    <ins>template&lt;&gt; class char_traits&lt;char16_t&gt;;</ins>
22405    <ins>template&lt;&gt; class char_traits&lt;char32_t&gt;;</ins>
22406    template&lt;&gt; class char_traits&lt;wchar_t&gt;;
22407 ...
22408 }
22409 </pre>
22410 </blockquote>
22411
22412
22413
22414
22415
22416 <hr>
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>
22423 <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
22431   argument.
22432 </p>
22433 <p>
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.
22437 </p>
22438
22439
22440 <p><b>Proposed resolution:</b></p>
22441 <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>.
22447 </p>
22448
22449
22450 <p><b>Rationale:</b></p>
22451 Already fixed in WP.
22452
22453
22454
22455
22456
22457 <hr>
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>
22464 <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. 
22473 </p>
22474
22475 <p>
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.
22485 </p>
22486
22487 <p>
22488 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
22489 </p>
22490
22491 <p>
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.
22500 </p>
22501
22502 <p><i>[
22503 Sophia Antipolis:
22504 ]</i></p>
22505
22506
22507 <blockquote>
22508 On going question of extern pointer vs. inline functions for interface.
22509 </blockquote>
22510
22511 <p><i>[
22512 Pre-San Francisco:
22513 ]</i></p>
22514
22515
22516 <blockquote>
22517 <p>
22518 Beman Dawes reports that this proposal is unimplementable, and thus NAD.
22519 </p>
22520 <p>
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.
22527 </p>
22528
22529 </blockquote>
22530
22531
22532 <p><b>Proposed resolution:</b></p>
22533 <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.
22538 </p>
22539
22540 <p>
22541 Change 19.5.1.1 [syserr.errcat.overview] Class
22542 <tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
22543 indicated:
22544 </p>
22545
22546 <blockquote><pre><del>const error_category&amp; get_generic_category();</del>
22547 <del>const error_category&amp; get_system_category();</del>
22548
22549 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
22550 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
22551 </pre></blockquote>
22552
22553 <p>
22554 Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
22555 </p>
22556
22557 <blockquote>
22558 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
22559 </pre>
22560 <p>
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>.
22564 </p>
22565
22566 <p>
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>.
22571 </p>
22572
22573 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
22574 </pre>
22575
22576 <p>
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>.
22580 </p>
22581
22582 <p>
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:
22587 </p>
22588
22589 <p>
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>]
22598 </p>
22599 </blockquote>
22600
22601 <p>
22602 Change 19.5.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
22603 </p>
22604
22605 <blockquote><pre>class error_code {
22606 public:
22607   ...;
22608   <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22609   ...
22610   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22611   ...
22612   const error_category<del>&amp;</del><ins>*</ins> category() const;
22613   ...
22614 private:
22615   int val_;                    // exposition only
22616   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
22617 </pre></blockquote>
22618
22619 <p>
22620 Change 19.5.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
22621 </p>
22622
22623 <blockquote>
22624 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22625 </pre>
22626 <p>
22627 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
22628 </p>
22629 <p>
22630 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22631 </p>
22632 <p>
22633 <i>Throws:</i> Nothing.
22634 </p>
22635 </blockquote>
22636
22637 <p>
22638 Change 19.5.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
22639 </p>
22640
22641 <blockquote>
22642 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22643 </pre>
22644 <p>
22645 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22646 </p>
22647 <p>
22648 <i>Throws:</i> Nothing.
22649 </p>
22650 </blockquote>
22651
22652 <p>
22653 Change 19.5.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
22654 </p>
22655
22656 <blockquote>
22657 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
22658 </pre>
22659
22660 <p>
22661 <i>Returns:</i> <tt>cat_</tt>.
22662 </p>
22663 <p>
22664 <i>Throws:</i> Nothing.
22665 </p>
22666 </blockquote>
22667
22668 <p>
22669 Change 19.5.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
22670 </p>
22671
22672 <blockquote>
22673 <pre>class error_condition {
22674 public:
22675   ...;
22676   <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22677   ...
22678   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22679   ...
22680   const error_category<del>&amp;</del><ins>*</ins> category() const;
22681   ...
22682 private:
22683   int val_;                    // exposition only
22684   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
22685 </pre>
22686 </blockquote>
22687
22688 <p>
22689 Change 19.5.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
22690 </p>
22691
22692 <blockquote>
22693 <pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22694 </pre>
22695 <p>
22696 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
22697 </p>
22698 <p>
22699 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22700 </p>
22701 <p>
22702 <i>Throws:</i> Nothing.
22703 </p>
22704 </blockquote>
22705
22706 <p>
22707 Change 19.5.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
22708 </p>
22709
22710 <blockquote>
22711 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22712 </pre>
22713 <p>
22714 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22715 </p>
22716 <p>
22717 <i>Throws:</i> Nothing.
22718 </p>
22719 </blockquote>
22720
22721 <p>
22722 Change 19.5.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
22723 </p>
22724
22725 <blockquote>
22726 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
22727 </pre>
22728 <p>
22729 <i>Returns:</i> <tt>cat_</tt>.
22730 </p>
22731 <p>
22732 <i>Throws:</i> Nothing.
22733 </p>
22734 </blockquote>
22735
22736 <p>
22737 Throughout 19.5 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
22738 Appears approximately six times.
22739 </p>
22740
22741 <p>
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()-&gt;equivalent(</tt>".
22745 </p>
22746
22747 <p>
22748 Change 19.5.6.1 [syserr.syserr.overview] Class system_error overview as indicated:
22749 </p>
22750
22751 <blockquote><pre>public:
22752   system_error(error_code ec, const string&amp; what_arg);
22753   system_error(error_code ec);
22754   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
22755       const string&amp; what_arg);
22756   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
22757 </pre></blockquote>
22758
22759 <p>
22760 Change 19.5.6.2 [syserr.syserr.members] Class system_error members as indicated:
22761 </p>
22762
22763 <blockquote>
22764 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
22765 </pre>
22766 <blockquote>
22767 <p>
22768 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22769 </p>
22770 <p>
22771 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22772 <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
22773 </p>
22774 </blockquote>
22775
22776 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
22777 </pre>
22778 <blockquote>
22779 <p>
22780 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22781 </p>
22782 <p>
22783 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22784 <tt>strcmp(runtime_error::what(), "") == 0</tt>.
22785 </p>
22786 </blockquote>
22787 </blockquote>
22788
22789
22790
22791 <p><b>Rationale:</b></p>
22792 <p><i>[
22793 San Francisco:
22794 ]</i></p>
22795
22796
22797 <blockquote>
22798 NAD because Beman said so.
22799 </blockquote>
22800
22801
22802
22803
22804
22805 <hr>
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>
22812 <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.
22816 </p>
22817
22818 <p><i>[
22819 San Francisco:
22820 ]</i></p>
22821
22822
22823 <blockquote>
22824 <p>
22825 This is a placeholder defect to remind us to review the table once we've
22826 stopped adding headers to the library.
22827 </p>
22828 <p>
22829 Three new headers that need to be added to the list:
22830 </p>
22831 <blockquote><pre>&lt;initializer_list&gt; &lt;concept&gt; &lt;iterator_concepts&gt;
22832 </pre></blockquote>
22833 <p>
22834 <tt>&lt;iterator_concepts&gt;</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.
22837 </p>
22838 <p>
22839 Robert: What about <tt>reference_closure</tt>? It's currently in
22840 <tt>&lt;functional&gt;</tt>.
22841 </p>
22842 </blockquote>
22843
22844 <p><i>[
22845 Post Summit Daniel adds:
22846 ]</i></p>
22847
22848
22849 <blockquote>
22850 <ol>
22851 <li>
22852 The comment regarding <tt>reference_closure</tt> seems moot since it was just
22853 recently decided to remove that.
22854 </li>
22855 <li>
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>&lt;initializer_list&gt;</tt> to the include list
22860 of freestanding.
22861 </li>
22862 </ol>
22863 </blockquote>
22864
22865 <p><i>[
22866 2009-07 Frankfurt:
22867 ]</i></p>
22868
22869
22870 <blockquote>
22871 <p>
22872 Addressed by paper
22873 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>.
22874 </p>
22875 <p>
22876 Move to NAD.
22877 </p>
22878 </blockquote>
22879
22880
22881
22882 <p><b>Proposed resolution:</b></p>
22883
22884
22885
22886
22887
22888 <hr>
22889 <h3><a name="837"></a>837. 
22890    <code>basic_ios::copyfmt()</code> overly loosely specified
22891  </h3>
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>
22897    <p>
22898
22899 The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:
22900
22901    </p>
22902    <blockquote>
22903
22904 <i>Effects</i>: If <code>(this == &amp;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
22907
22908      <ul>
22909        <li>
22910
22911 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
22912
22913        </li>
22914        <li>
22915
22916 <code>exceptions()</code> is altered last by
22917 calling <code>exceptions(rhs.except)</code>
22918
22919        </li>
22920        <li>
22921
22922 the contents of arrays pointed at by <code>pword</code>
22923 and <code>iword</code> are copied not the pointers themselves
22924
22925        </li>
22926      </ul>
22927    </blockquote>
22928    <p>
22929
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.
22932
22933 </p>
22934
22935 <p><i>[
22936 Batavia (2009-05):
22937 ]</i></p>
22938
22939 <blockquote>
22940 We agree with the proposed resolution.
22941 Move to NAD Editorial.
22942 </blockquote>
22943
22944
22945 <p><b>Proposed resolution:</b></p>
22946 <p>
22947
22948 I propose to tighten things up by adding a <i>Postcondition</i> clause
22949 to the function like so:
22950
22951    </p>
22952    <blockquote>
22953      <i>Postconditions:</i>
22954
22955      <table border="1">
22956        <thead>
22957          <tr>
22958            <th colspan="2"><code>copyfmt()</code> postconditions</th>
22959          </tr>
22960          <tr>
22961            <th>Element</th>
22962            <th>Value</th>
22963          </tr>
22964        </thead>
22965        <tbody>
22966          <tr>
22967            <td><code>rdbuf()</code></td>
22968            <td><i>unchanged</i></td>
22969          </tr>
22970          <tr> 
22971            <td><code>tie()</code></td>
22972            <td><code>rhs.tie()</code></td>
22973          </tr>
22974          <tr> 
22975            <td><code>rdstate()</code></td>
22976            <td><i>unchanged</i></td>
22977          </tr>
22978          <tr> 
22979            <td><code>exceptions()</code></td>
22980            <td><code>rhs.exceptions()</code></td>
22981          </tr>
22982          <tr> 
22983            <td><code>flags()</code></td>
22984            <td><code>rhs.flags()</code></td>
22985          </tr>
22986          <tr> 
22987            <td><code>width()</code></td>
22988            <td><code>rhs.width()</code></td>
22989          </tr>
22990          <tr> 
22991            <td><code>precision()</code></td>
22992            <td><code>rhs.precision()</code></td>
22993          </tr>
22994          <tr> 
22995            <td><code>fill()</code></td>
22996            <td><code>rhs.fill()</code></td>
22997          </tr>
22998          <tr> 
22999            <td><code>getloc()</code></td>
23000            <td><code>rhs.getloc()</code></td>
23001          </tr>
23002        </tbody>
23003      </table>
23004    </blockquote>
23005    <p>
23006
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>
23009 effects.
23010
23011    </p>
23012    <p>
23013
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
23016 already there.
23017
23018    </p>
23019  
23020
23021
23022
23023 <hr>
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>
23030 <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&lt;int, huge_thingy&gt;</tt>)
23038 this can be a big win.
23039 </p>
23040
23041 <p>
23042 <b>Suggested resolution:</b>
23043 </p>
23044
23045 <p>
23046 Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
23047 </p>
23048 <blockquote><pre> 
23049 void splice(list&lt;T,Allocator&gt;&amp;&amp; x);
23050 void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
23051 void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
23052 </pre></blockquote>
23053
23054 <p>
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.)
23057 </p>
23058  
23059 <blockquote><pre> 
23060 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
23061 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
23062 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
23063 </pre></blockquote>
23064
23065 <p><i>[
23066 Sophia Antipolis:
23067 ]</i></p>
23068
23069
23070 <blockquote>
23071 <p>
23072 Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
23073 </p>
23074 <p>
23075 <tt>forward_list</tt> already has <tt>splice_after</tt>.
23076 </p>
23077 <p>
23078 Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
23079 </p>
23080 <p>
23081 Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
23082 </p>
23083 <p>
23084 Howard: <tt>adopt</tt>?
23085 </p>
23086 <p>
23087 Jens: <tt>absorb</tt>?
23088 </p>
23089 <p>
23090 Alan: <tt>subsume</tt>?
23091 </p>
23092 <p>
23093 Robert: <tt>recycle</tt>?
23094 </p>
23095 <p>
23096 Howard: <tt>transfer</tt>? (but no direction)
23097 </p>
23098 <p>
23099 Jens: <tt>transfer_from</tt>. No.
23100 </p>
23101 <p>
23102 Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
23103 </p>
23104 <p>
23105 Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
23106 </p>
23107 </blockquote>
23108
23109 <p><i>[
23110 San Francisco:
23111 ]</i></p>
23112
23113
23114 <blockquote>
23115 <p>
23116 Martin: this would possibly outlaw an implementation technique that is
23117 currently in use; caching nodes in containers.
23118 </p>
23119 <p>
23120 Alan: if you cache in the allocator, rather than the individual
23121 container, this proposal doesn't interfere with that.
23122 </p>
23123 <p>
23124 Martin: I'm not opposed to this, but I'd like to see an implementation
23125 that demonstrates that it works.
23126 </p>
23127 </blockquote>
23128
23129 <p><i>[
23130 2009-07 Frankfurt:
23131 ]</i></p>
23132
23133
23134 <blockquote>
23135 NAD Future.
23136 </blockquote>
23137
23138 <p><i>[
23139 2009-09-19 Howard adds:
23140 ]</i></p>
23141
23142
23143 <blockquote>
23144 <p>
23145 I'm not disagreeing with the NAD Future resolution.  But when the future gets
23146 here, here is a possibility worth exploring:
23147 </p>
23148
23149 <blockquote>
23150 <p>
23151 Add to the "unique" associative containers:
23152 </p>
23153
23154 <blockquote><pre>typedef <i>details</i>      node_ptr;
23155
23156 node_ptr             remove(const_iterator p);
23157 pair&lt;iterator, bool&gt; insert(node_ptr&amp;&amp; nd);
23158 iterator             insert(const_iterator p, node_ptr&amp;&amp; nd);
23159 </pre></blockquote>
23160
23161 <p>
23162 And add to the "multi" associative containers:
23163 </p>
23164
23165 <blockquote><pre>typedef <i>details</i> node_ptr;
23166
23167 node_ptr remove(const_iterator p);
23168 iterator insert(node_ptr&amp;&amp; nd);
23169 iterator insert(const_iterator p, node_ptr&amp;&amp; nd);
23170 </pre></blockquote>
23171
23172 <p>
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.
23178 </p>
23179
23180 <p>
23181 The <tt>node_ptr</tt> offers "<tt>const</tt>-free" access to the node's
23182 <tt>value_type</tt>.
23183 </p>
23184
23185 <p>
23186 With this interface, clients have a great deal of flexibility:
23187 </p>
23188
23189 <ul>
23190 <li>
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
23193 asks for.
23194 </li>
23195 <li>
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
23198 allocating a node.
23199 </li>
23200 <li>
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.
23204 </li>
23205 <li>
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.
23208 </li>
23209 <li>
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&lt;T, C1, A&gt;</tt>
23212 to <tt>set&lt;T, C2, A&gt;</tt> (for example).
23213 </li>
23214 </ul>
23215
23216 <p>
23217 Here is how the customer might use this functionality:
23218 </p>
23219
23220 <ul>
23221 <li>
23222 <p>
23223 Splice a node from one container to another:
23224 </p>
23225 <blockquote><pre>m2.insert(m1.remove(i));
23226 </pre></blockquote>
23227 </li>
23228
23229 <li>
23230 <p>
23231 Change the "key" in a <tt>std::map</tt> without the cost of node reallocation:
23232 </p>
23233 <blockquote><pre>auto p = m.remove(i);
23234 p-&gt;first = new_key;
23235 m.insert(std::move(p));
23236 </pre></blockquote>
23237 </li>
23238
23239 <li>
23240 <p>
23241 Change the "value" in a <tt>std::set</tt> without the cost of node reallocation:
23242 </p>
23243 <blockquote><pre>auto p = s.remove(i);
23244 *p = new_value;
23245 s.insert(std::move(p));
23246 </pre></blockquote>
23247 </li>
23248
23249 <li>
23250 <p>
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>):
23253 </p>
23254 <blockquote><pre>MoveOnly x = std::move(*s.remove(i));
23255 </pre></blockquote>
23256 <ol>
23257 <li>
23258 <tt>remove(i)</tt> transfers ownership of the node from the set to a temporary
23259 <tt>node_ptr</tt>.
23260 </li>
23261 <li>
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.
23264 </li>
23265 <li>
23266 The rvalue <tt>MoveOnly</tt> is move constructed into <tt>x</tt> from
23267 the <tt>node_ptr</tt>.
23268 </li>
23269 <li>
23270 <tt>~node_ptr()</tt> destructs the moved-from <tt>MoveOnly</tt> and deallocates
23271 the node.
23272 </li>
23273 </ol>
23274
23275 <p>
23276 Contrast this with the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a> solution:
23277 </p>
23278 <blockquote><pre>MoveOnly x = std::move(s.extract(i).first);
23279 </pre></blockquote>
23280
23281 <p>
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.
23289 </p>
23290
23291 </li>
23292 </ul>
23293
23294 <p>
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"
23298 containers.
23299 </p>
23300
23301 <p>
23302 Lightly prototyped.  No implementation problems.  Appears to work great
23303 for the client.
23304 </p>
23305
23306 </blockquote>
23307 </blockquote>
23308
23309
23310
23311 <p><b>Proposed resolution:</b></p>
23312
23313
23314
23315
23316
23317 <hr>
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>
23324 <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).
23330 </p>
23331
23332
23333 <p><b>Proposed resolution:</b></p>
23334 <p>
23335 Change the synopsis in 20.3 [utility] to read:
23336 </p>
23337
23338 <blockquote><pre>template &lt;class T1, class T2 <ins>= T1</ins>&gt; struct pair;
23339 </pre></blockquote>
23340
23341 <p>
23342 Change 20.3.5 [pairs] to read:
23343 </p>
23344
23345 <blockquote><pre>namespace std {
23346  template &lt;class T1, class T2 <ins>= T1</ins>&gt;
23347  struct pair {
23348    typedef T1 first_type;
23349    typedef T2 second_type;
23350    ...
23351 </pre></blockquote>
23352
23353
23354 <p><b>Rationale:</b></p>
23355 <tt>std::pair</tt> is a heterogeneous container.
23356
23357
23358
23359
23360
23361 <hr>
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>
23368    <p>
23369
23370 In specifying the names of macros and types defined in
23371 header <code>&lt;stdint.h&gt;</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).
23376
23377    </p>
23378    <p>
23379
23380 In  cstdint.syn Header <code>&lt;cstdint&gt;</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. 
23384
23385    </p>
23386    <p>
23387    </p>
23388
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.
23393
23394    <p>
23395
23396 Finally, the section is missing the usual table of symbols defined
23397 in that header, making it inconsistent with the rest of the
23398 specification.
23399
23400    </p>
23401  
23402  <p><b>Proposed resolution:</b></p>
23403    <p>
23404
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.
23409
23410    </p>
23411    <p>
23412
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.
23416
23417    </p>
23418    <p>
23419
23420 To this effect, in  cstdint.syn
23421 Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
23422 synopsis and paragraph 1 with the following text:
23423
23424    </p>
23425    <blockquote>
23426      <p>
23427        </p><ol>
23428          <li>
23429
23430 In the names defined in the <code>&lt;cstdint&gt;</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.
23440
23441          </li>
23442        </ol>
23443      <p></p>
23444      <pre>namespace std {
23445
23446    // required types
23447
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;
23453
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;
23458
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;
23464
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;
23469
23470    // Greatest-width integer types
23471    typedef <i>signed integer type</i>   intmax_t;
23472    typedef <i>unsigned integer type</i> uintmax_t;
23473
23474    // optionally defined types
23475
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;
23479
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;
23484
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;
23489
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;
23493
23494 }</pre>
23495    </blockquote>
23496    <p>
23497
23498 [Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
23499
23500    </p>
23501    <blockquote>
23502      Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
23503      <table border="1">
23504        <thead>
23505          <tr>
23506            <th>Type</th>
23507            <th colspan="3">Name(s)</th>
23508          </tr>
23509        </thead>
23510        <tbody>
23511          <tr>
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>
23516          </tr>
23517          <tr>
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>
23521          </tr>
23522          <tr>
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>
23526          </tr>
23527          <tr>
23528            <td><tt>INTPTR_MIN</tt></td>
23529            <td><tt>INTPTR_MAX</tt></td>
23530            <td><tt>UINTPTR_MAX</tt></td>
23531          </tr>
23532          <tr>
23533            <td><tt>INTMAX_MIN</tt></td>
23534            <td><tt>INTMAX_MAX</tt></td>
23535            <td><tt>UINTMAX_MAX</tt></td>
23536          </tr>
23537          <tr>
23538            <td><tt>PTRDIFF_MIN</tt></td>
23539            <td><tt>PTRDIFF_MAX</tt></td>
23540            <td><tt>PTRDIFF_MAX</tt></td>
23541          </tr>
23542          <tr>
23543            <td><tt>SIG_ATOMIC_MIN</tt></td>
23544            <td><tt>SIG_ATOMIC_MAX</tt></td>
23545            <td><tt>SIZE_MAX</tt></td>
23546          </tr>
23547          <tr>
23548            <td><tt>WCHAR_MIN</tt></td>
23549            <td><tt>WCHAR_MAX</tt></td>
23550          <td></td>
23551          </tr>
23552          <tr>
23553            <td><tt>WINT_MIN</tt></td>
23554            <td><tt>WINT_MAX</tt></td>
23555            <td></td>
23556          </tr>
23557          <tr>
23558            <td><tt>INT<i>N</i>_C()</tt></td>
23559            <td><tt>UINT<i>N</i>_C()</tt></td>
23560            <td></td>
23561          </tr>
23562          <tr>
23563            <td><tt>INTMAX_C()</tt></td>
23564            <td><tt>UINTMAX_C()</tt></td>
23565            <td></td>
23566          </tr>
23567          <tr>
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>
23571            <td></td>
23572          </tr>
23573          <tr>
23574            <td><tt>int_fast<i>N</i>_t</tt></td>
23575            <td><tt>uint_fast<i>N</i>_t</tt></td>
23576            <td></td>
23577          </tr>
23578          <tr>
23579            <td><tt>int_least<i>N</i>_t</tt></td>
23580            <td><tt>uint_least<i>N</i>_t</tt></td>
23581            <td></td>
23582          </tr>
23583          <tr>
23584            <td><tt>intptr_t</tt></td>
23585            <td><tt>uintptr_t</tt></td>
23586            <td></td>
23587          </tr>
23588          <tr>
23589            <td><tt>intmax_t</tt></td>
23590            <td><tt>uintmax_t</tt></td>
23591            <td></td>
23592          </tr>
23593        </tbody>
23594      </table>
23595    </blockquote>
23596  
23597
23598
23599
23600
23601 <hr>
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>
23608 <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&lt;root_class&gt;</tt> and provide a partial specialization that worked
23618 for all derived classes.
23619 </p>
23620
23621 <p>
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.
23628 </p>
23629
23630 <p>
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.
23633 </p>
23634
23635
23636 <p><b>Proposed resolution:</b></p>
23637 <p>
23638 Add the following to the synopsis in 20.7.2 [meta.type.synop] under "other transformations":
23639 </p>
23640
23641 <blockquote><pre>template&lt; class T &gt; struct direct_base_class;
23642 template&lt; class T &gt; struct direct_derived_class;
23643 template&lt; class T &gt; struct root_base_class;
23644 </pre></blockquote>
23645
23646 <p>
23647 Add three new entries to table 51 (20.7.7.6 [meta.trans.other]) with the following content
23648 </p>
23649
23650 <blockquote>
23651 <table border="1">
23652 <tbody><tr>
23653 <th>Template</th><th>Condition</th><th>Comments</th>
23654 </tr>
23655 <tr>
23656 <td><tt>template&lt; class T &gt; 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>
23660 </tr>
23661 <tr>
23662 <td><tt>template&lt; class T &gt; 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>
23667 </tr>
23668 <tr>
23669 <td><tt>template&lt; class T &gt; 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>
23673 </tr>
23674 </tbody></table>
23675 </blockquote>
23676
23677
23678
23679 <p><b>Rationale:</b></p>
23680 2008-9-16 San Francisco:  Issue pulled by author prior to being reviewed by the LWG.
23681
23682
23683
23684
23685
23686 <hr>
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>
23693 <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
23696 out.
23697 </p>
23698
23699 <p>
23700 In "C," this array usage is possible:
23701 </p>
23702
23703 <blockquote><pre>int ar[] = {1, 4, 6};
23704 </pre></blockquote>
23705
23706 <p>
23707 But for C++, 
23708 </p>
23709
23710 <blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
23711 </pre></blockquote>
23712
23713 <p>
23714 Instead, the second parameter of the <tt>array</tt> template must be
23715 explicit, like so:
23716 </p>
23717
23718 <blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
23719 </pre></blockquote>
23720
23721 <p>
23722 Doug Gregor proposes the following solution, that assumes
23723 generalized initializer lists.
23724 </p>
23725
23726 <blockquote><pre>template&lt;typename T, typename... Args&gt;
23727 inline array&lt;T, sizeof...(Args)&gt; 
23728 make_array(Args&amp;&amp;... args) 
23729 { return { std::forward&lt;Args&gt;(args)... };  }
23730 </pre></blockquote>
23731
23732 <p>
23733 Then, the way to build an <tt>array</tt> from a list of unknown size is:
23734 </p>
23735
23736 <blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
23737 </pre></blockquote>
23738
23739 <p><i>[
23740 San Francisco:
23741 ]</i></p>
23742
23743
23744 <blockquote>
23745 <p>
23746 Benjamin: Move to Ready?
23747 </p>
23748 <p>
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.
23751 </p>
23752 <p>
23753 Alisdair: the constraints are wrong, they should be
23754 </p>
23755 <blockquote><pre>template&lt;ValueType T, ValueType... Args&gt;
23756 requires Convertible&lt;Args, T&gt;...
23757 array&lt;T, sizeof...(Args)&gt; make_array(Args&amp;&amp;... args);
23758 </pre></blockquote>
23759 <p>
23760 Alidair: this would be useful if we had a constexpr version.
23761 </p>
23762 <p>
23763 Bjarne: this is probably useful for arrays with a small number of
23764 elements, but it's not clearly useful otherwise.
23765 </p>
23766 <p>
23767 Consensus is to move to Open.
23768 </p>
23769 </blockquote>
23770
23771 <p><i>[
23772 2009-06-07 Daniel adds:
23773 ]</i></p>
23774
23775
23776 <blockquote>
23777 <p>
23778 I suggest a fix and a simplification of the current proposal: Recent
23779 prototyping by
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.
23783 the expression
23784 <tt>make_array&lt;double&gt;(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
23787 given e.g.
23788 </p>
23789 <blockquote><pre>int f();
23790 double g();
23791 </pre></blockquote>
23792 <p>
23793 we probably want to support
23794 </p>
23795 <blockquote><pre>make_array&lt;double&gt;(f(), g());
23796 </pre></blockquote>
23797
23798 <p>
23799 as well. To make this feasible, the currently suggested expansion
23800 </p>
23801
23802 <blockquote><pre>{ std::forward&lt;Args&gt;(args)... }
23803 </pre></blockquote>
23804
23805 <p>
23806 needs to be replaced by
23807 </p>
23808
23809 <blockquote><pre>{ static_cast&lt;T&gt;(std::forward&lt;Args&gt;(args))... }
23810 </pre></blockquote>
23811
23812 <p>
23813 which is safe, because we already ensure convertibility via the
23814 element-wise <tt>Convertible&lt;Args, T&gt;</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.
23818 </p>
23819
23820 <p>
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:
23824 </p>
23825
23826 <blockquote><pre>template&lt;typename... Args&gt;
23827 array&lt;typename decay&lt;typename common_type&lt;Args...&gt;::type&gt;::type,
23828 sizeof...(Args)&gt;
23829 make_array(Args&amp;&amp;... args);
23830 </pre></blockquote>
23831
23832 <p>
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
23842 the currently
23843 missing <tt>Constructible&lt;Vi, Ti&amp;&amp;&gt;</tt> requirement for those functions. The following
23844 proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
23845 deduction is
23846 explicitly wanted for standardization, here the implementation
23847 </p>
23848
23849 <blockquote><pre>auto concept DC&lt;typename... T&gt; {
23850   typename type = typename decay&lt;typename common_type&lt;T...&gt;::type&gt;::type;
23851 }
23852 </pre></blockquote>
23853
23854 <p>
23855 where <tt>C</tt> is identical to <tt>DC&lt;Args...&gt;::type</tt> in the proposed resolution below.
23856 </p>
23857 <p>
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.
23862 </p>
23863
23864 <p><b>Suggested Resolution:</b></p>
23865
23866 <ol>
23867 <li>
23868 <p>
23869 Add to the array synopsis in 23.3 [sequences]:
23870 </p>
23871 <blockquote><pre><ins>
23872 template&lt;ReferentType... Args&gt;
23873 requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
23874 array&lt;C, sizeof...(Args)&gt;
23875 make_array(Args&amp;&amp;... args);
23876 </ins>
23877 </pre></blockquote>
23878 </li>
23879
23880 <li>
23881 <p>
23882 Append after 23.3.1.8 [array.tuple] Tuple interface to class template array
23883 the following new section:
23884 </p>
23885 <blockquote>
23886 <p>
23887 23.4.1.7 Array creation functions [array.creation]
23888 </p>
23889
23890 <pre><ins>
23891 template&lt;ReferentType... Args&gt;
23892 requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
23893 array&lt;C, sizeof...(Args)&gt;
23894 make_array(Args&amp;&amp;... args);</ins>
23895 </pre>
23896
23897 <blockquote>
23898 <p><ins>
23899 Let <tt>C</tt> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.
23900 </ins></p>
23901 <p>
23902 <ins><i>Returns:</i> an <tt>array&lt;C, sizeof...(Args)&gt;</tt> initialized with
23903 <tt>{ static_cast&lt;C&gt;(std::forward&lt;Args&gt;(args))... }</tt>.
23904 </ins></p>
23905 </blockquote>
23906 </blockquote>
23907
23908 </li>
23909
23910 </ol>
23911
23912 </blockquote>
23913
23914 <p><i>[
23915 2009-07 Frankfurt:
23916 ]</i></p>
23917
23918
23919 <blockquote>
23920 <p>
23921 The proposed resolution uses concepts.
23922 </p>
23923 <p>
23924 Daniel to rewrite the proposed resolution.
23925 </p>
23926 <p>
23927 Leave Open.
23928 </p>
23929 </blockquote>
23930
23931 <p><i>[
23932 2009-07-25 Daniel provides rewritten proposed resolution.
23933 ]</i></p>
23934
23935
23936 <p><i>[
23937 2009-10 Santa Cruz:
23938 ]</i></p>
23939
23940
23941 <blockquote>
23942 Argument for NAD future: everything about this could be added on. This
23943 does not require changes to the existing text.
23944 </blockquote>
23945
23946
23947
23948 <p><b>Proposed resolution:</b></p>
23949
23950 <ol>
23951 <li>
23952 <p>
23953 Add to the array synopsis in 23.3 [sequences]:
23954 </p>
23955
23956 <blockquote><pre><ins>template&lt;class... Args&gt;
23957   array&lt;<i>CT</i>, sizeof...(Args)&gt;
23958   make_array(Args&amp;&amp;... args);</ins>
23959 </pre></blockquote>
23960 </li>
23961
23962 <li>
23963 <p>
23964 Append after 23.3.1.8 [array.tuple] "Tuple interface to class template array" the
23965 following new section:
23966 </p>
23967
23968 <blockquote>
23969 <p>
23970 <ins>XX.X.X.X Array creation functions [array.creation]</ins>
23971 </p>
23972
23973 <pre><ins>
23974 template&lt;class... Args&gt;
23975 array&lt;<i>CT</i>, sizeof...(Args)&gt;
23976 make_array(Args&amp;&amp;... args)
23977 </ins></pre>
23978
23979 <blockquote>
23980 <p>
23981 <ins>Let <i>CT</i> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.</ins>
23982 </p>
23983 <p>
23984 <ins><i>Returns:</i> An <tt>array&lt;<i>CT</i>, sizeof...(Args)&gt;</tt> initialized with <tt>{
23985 static_cast&lt;<i>CT</i>&gt;(std::forward&lt;Args&gt;(args))... }</tt>.</ins>
23986 </p>
23987
23988 <p><ins>
23989 [<i>Example:</i>
23990 </ins></p>
23991 <blockquote><pre><ins>
23992 int i = 0; int&amp; ri = i;
23993 make_array(42u, i, 2.78, ri);
23994 </ins></pre></blockquote>
23995 <p><ins>
23996 returns an array of type
23997 </ins></p>
23998 <blockquote><pre><ins>
23999 array&lt;double, 4&gt;
24000 </ins></pre></blockquote>
24001
24002 <p><ins>
24003 \97<i>end example</i>]</ins>
24004 </p>
24005 </blockquote>
24006 </blockquote>
24007 </li>
24008
24009 </ol>
24010
24011
24012
24013
24014
24015
24016
24017
24018 <hr>
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>
24025 <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.
24036 </p>
24037 <p>
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.
24046 </p>
24047 <p>
24048 A simple picture of a deque:
24049 </p>
24050 <blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
24051 </pre></blockquote>
24052 <p>
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>.
24057 </p>
24058 <p>
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).
24069 </p>
24070 <p>
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:
24074 </p>
24075
24076 <p><i>[
24077 San Francisco:
24078 ]</i></p>
24079
24080
24081 <blockquote>
24082 <p>
24083 Hans: should the Returns clause for capacity read "1 Returns: A lower
24084 bound..." rather than "1 Returns: An upper bound..."
24085 </p>
24086 <p>
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.
24090 </p>
24091 </blockquote>
24092
24093
24094
24095 <p><b>Proposed resolution:</b></p>
24096
24097 <p>
24098 Add new signatures to synopsis in 23.3.2 [deque]:
24099 </p>
24100
24101 <blockquote><pre>size_type capacity() const;
24102 bool reserve(size_type n);
24103 </pre></blockquote>
24104
24105 <p>
24106 Add new signatures to 23.3.2.2 [deque.capacity]:
24107 </p>
24108
24109 <blockquote>
24110 <pre>size_type capacity() const;
24111 </pre>
24112 <blockquote>
24113 <p>
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.
24119 </p>
24120 <p>
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.
24125 </p>
24126 </blockquote>
24127 </blockquote>
24128
24129 <blockquote>
24130 <pre>bool reserve(size_type n);
24131 </pre>
24132 <blockquote>
24133 <p>
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.
24140 </p>
24141 <p>
24142 3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this  
24143 operation, and false otherwise.
24144 </p>
24145 <p>
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>.
24148 </p>
24149 <p>
24150 5 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
24151 </p>
24152 <p>
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>.
24160 </p>
24161 <p>
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.
24165 </p>
24166 </blockquote>
24167 </blockquote>
24168
24169 <p>
24170 And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
24171 </p>
24172
24173 <blockquote>
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.
24178 </blockquote>
24179
24180
24181 <p><b>Rationale:</b></p>
24182 Complication outweighs the benefit.
24183
24184
24185
24186
24187
24188 <hr>
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>
24195 <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
24198 comparisions!
24199 </p>
24200
24201 <p>
24202 This same issue also applies to:
24203 </p>
24204
24205 <ul>
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>
24211 </ul>
24212
24213 <p><i>[
24214 2009-03-30 Beman adds:
24215 ]</i></p>
24216
24217
24218 <blockquote>
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
24224 limited benefit.
24225 </blockquote>
24226
24227 <p><i>[
24228 2009-05-09 Alisdair adds:
24229 ]</i></p>
24230
24231
24232 <blockquote>
24233 <p>
24234 I'm not happy with NAD if we can find a simple solution.
24235 </p>
24236 <p>
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
24240 further cases.
24241 </p>
24242 </blockquote>
24243
24244 <p><i>[
24245 Batavia (2009-05):
24246 ]</i></p>
24247
24248 <blockquote>
24249 Pete to provide "straightforward" wording.
24250 Move to NAD Editorial.
24251 </blockquote>
24252
24253
24254 <p><b>Proposed resolution:</b></p>
24255 <p>
24256 Recommend NAD.
24257 </p>
24258
24259
24260
24261
24262
24263 <hr>
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>
24270 <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>.
24274 </p>
24275 <p>
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.
24278 </p>
24279 <p>
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>?
24283 </p>
24284
24285 <p><i>[
24286 Batavia (2009-05):
24287 ]</i></p>
24288
24289 <blockquote>
24290 <p>
24291 Tom's impression is that the issue is about the <tt>failbit</tt>, etc.
24292 </p>
24293 <p>
24294 Bill responds that the stream is now closed,
24295 and any status bits remain unchanged.
24296 </p>
24297 <p>
24298 See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members].
24299 </p>
24300 <p>
24301 We prefer not to add wording to say that nothing changes.
24302 Move to NAD.
24303 </p>
24304 </blockquote>
24305
24306
24307 <p><b>Proposed resolution:</b></p>
24308 <p>
24309 </p>
24310
24311
24312
24313
24314
24315 <hr>
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>
24323 <p>
24324 There's an error in 29.6 [atomics.types.operations]/p9:
24325 </p>
24326
24327 <blockquote>
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;
24331 </pre>
24332 <blockquote>
24333 <p>
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>.
24336 </p>
24337 </blockquote>
24338 </blockquote>
24339
24340 <p>
24341 I believe that this should state
24342 </p>
24343 <blockquote>
24344 shall not be <tt>memory_order_release</tt>.
24345 </blockquote>
24346
24347 <p>
24348 There's also an error in 29.6 [atomics.types.operations]/p17:
24349 </p>
24350
24351 <blockquote>
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> ...
24357 </blockquote>
24358 <p>
24359 I believe this should state
24360 </p>
24361 <blockquote>
24362 shall be replaced by the value <tt>memory_order_acquire</tt> ...
24363 </blockquote>
24364
24365
24366 <p><b>Proposed resolution:</b></p>
24367 <p>
24368 Change 29.6 [atomics.types.operations]/p9:
24369 </p>
24370
24371 <blockquote>
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;
24375 </pre>
24376 <blockquote>
24377 <p>
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>.
24380 </p>
24381 </blockquote>
24382 </blockquote>
24383
24384 <p>
24385 Change 29.6 [atomics.types.operations]/p17:
24386 </p>
24387
24388 <blockquote>
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> ...
24394 </blockquote>
24395
24396
24397
24398 <p><b>Rationale:</b></p>
24399 Already fixed by the time the LWG processed it.
24400
24401
24402
24403
24404
24405 <hr>
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>
24412 <p>
24413 From 26.6.2.1 [valarray.cons], paragraph 2:
24414 </p>
24415
24416 <blockquote><pre>explicit  valarray(size_t);
24417 </pre>
24418 <blockquote>
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>.
24421 </blockquote>
24422 </blockquote>
24423
24424 <p>
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:
24428 </p>
24429
24430 <blockquote>
24431 The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
24432 </blockquote>
24433 <p>
24434 with
24435 </p>
24436 <blockquote>
24437 The elements of the array are value-initialized.
24438 </blockquote>
24439
24440 <p>
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).
24444 </p>
24445
24446 <p><i>[
24447 Batavia (2009-05):
24448 ]</i></p>
24449
24450 <blockquote>
24451 We agree with the proposed resolution.
24452 Move to NAD Editorial.
24453 </blockquote>
24454
24455
24456 <p><b>Proposed resolution:</b></p>
24457 <p>
24458 Change 26.6.2.1 [valarray.cons], paragraph 2:
24459 </p>
24460
24461 <blockquote>
24462 <pre>explicit  valarray(size_t);
24463 </pre>
24464 <blockquote>
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>.
24468 </blockquote>
24469 </blockquote>
24470
24471 <p>
24472 Change 26.6.2.7 [valarray.members], paragraph 9:
24473 </p>
24474
24475 <blockquote>
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>]
24480 </blockquote>
24481
24482
24483
24484
24485
24486
24487 <hr>
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>
24493     <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.
24500     </p>
24501
24502     <p>
24503       Note that the key issue here is that "signed" + "integral type" !=
24504       "signed integral type".
24505       
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>.
24511       
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.
24515       
24516       As an example, if <code>T</code> is <code>unsigned char</code>, the
24517       expression <code>make_signed&lt;T&gt;::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 &lt; 0</code>).
24521     </p>
24522
24523 <p><i>[
24524 San Francisco:
24525 ]</i></p>
24526
24527
24528 <blockquote>
24529 Plum, Sebor to review.
24530 </blockquote>
24531
24532 <p><i>[
24533 Post Summit Daniel adds:
24534 ]</i></p>
24535
24536
24537 <blockquote>
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
24544 concepts.
24545 </blockquote>
24546
24547   
24548
24549   <p><b>Proposed resolution:</b></p>
24550     <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.
24554     </p>
24555     
24556     <p>
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...
24561     </p>
24562     <blockquote>
24563       <p>
24564         </p><ol>
24565           <li>
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>&lt;cstdint&gt;</code> header (18.1)...
24573           </li>
24574         </ol>
24575       <p></p>
24576     </blockquote>
24577
24578     <p>
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...
24584     </p>
24585     <blockquote>
24586       Table 40: Allocator requirements
24587       <table border="1">
24588         <thead>
24589           <tr>
24590             <th>expression</th>
24591             <th>return type</th>
24592             <th>assertion/note/pre/post-condition</th>
24593           </tr>
24594         </thead>
24595         <tbody>
24596           <tr>
24597             <td><tt>X::size_type</tt></td>
24598             <td>
24599               <del>unsigned integral type</del>
24600               <ins>unsigned integer type</ins>
24601             </td>
24602             <td>a type that can represent the size of the largest object in
24603             the allocation model.</td>
24604           </tr>
24605           <tr>
24606             <td><tt>X::difference_type</tt></td>
24607             <td>
24608               <del>signed integral type</del>
24609               <ins>signed integer type</ins>
24610             </td>
24611             <td>a type that can represent the difference between any two
24612             pointers in the allocation model.</td>
24613           </tr>
24614         </tbody>
24615       </table>
24616     </blockquote>
24617
24618     <p>
24619       The proposed change makes it clear that <tt>make_signed&lt;T&gt;::type</tt>
24620       must be one of the signed integer types as defined in 3.9.1. Ditto for
24621       <tt>make_unsigned&lt;T&gt;type</tt> and unsigned integer types.
24622       20.7.7.3 [meta.trans.sign] table 48...
24623     </p>
24624     <blockquote>
24625       Table 48: Sign modifications
24626       <table border="1">
24627         <thead>
24628           <tr>
24629             <th>Template</th>
24630             <th>Comments</th>
24631           </tr>
24632         </thead>
24633         <tbody>
24634           <tr>
24635             <td>
24636               <tt>template &lt;class T&gt; struct make_signed;</tt>
24637             </td>
24638             <td>
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
24651               <code>T</code>.
24652
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.
24656             </td>
24657           </tr>
24658           <tr>
24659             <td>
24660               <tt>template &lt;class T&gt; struct make_unsigned;</tt>
24661             </td>
24662             <td>
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>.
24676
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.
24680             </td>
24681           </tr>
24682         </tbody>
24683       </table>
24684     </blockquote>
24685
24686
24687     <p>
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]
24690
24691       The listed virtuals are all overloaded on signed and unsigned integer
24692       types, the new wording just maintains consistency.
24693
24694       22.4.2.1.2 [facet.num.get.virtuals] table 78...
24695     </p>
24696     <blockquote>
24697       Table 78: Integer Conversions
24698       <table border="1">
24699         <thead>
24700           <tr>
24701             <th>State</th>
24702             <th><tt>stdio</tt> equivalent</th>
24703           </tr>
24704         </thead>
24705         <tbody>
24706           <tr>
24707             <td><tt>basefield == oct</tt></td>
24708             <td><tt>%o</tt></td>
24709           </tr>
24710           <tr>
24711             <td><tt>basefield == hex</tt></td>
24712             <td><tt>%X</tt></td>
24713           </tr>
24714           <tr>
24715             <td><tt>basefield == 0</tt></td>
24716             <td><tt>%i</tt></td>
24717           </tr>
24718           <tr>
24719             <td><del>signed integral type</del><ins>signed integer
24720             type</ins></td>
24721             <td><tt>%d</tt></td>
24722           </tr>
24723           <tr>
24724             <td><del>unsigned integral type</del><ins>unsigned integer
24725             type</ins></td>
24726             <td><tt>%u</tt></td>
24727           </tr>
24728         </tbody>
24729       </table>
24730     </blockquote>
24731
24732     
24733     
24734     <p>
24735       Rationale is same as above.
24736       22.4.2.2.2 [facet.num.put.virtuals] table 80...
24737     </p>
24738     <blockquote>
24739       Table 80: Integer Conversions
24740       <table border="1">
24741         <thead>
24742           <tr>
24743             <th>State</th>
24744             <th><tt>stdio</tt> equivalent</th>
24745           </tr>
24746         </thead>
24747         <tbody>
24748           <tr>
24749             <td><tt>basefield == ios_base::oct</tt></td>
24750             <td><tt>%o</tt></td>
24751           </tr>
24752           <tr>
24753             <td><tt>(basefield == ios_base::hex) &amp;&amp;
24754             !uppercase</tt></td>
24755             <td><tt>%x</tt></td>
24756           </tr>
24757           <tr>
24758             <td><tt>(basefield == ios_base::hex)</tt></td>
24759             <td><tt>%X</tt></td>
24760           </tr>
24761           <tr>
24762             <td><tt>basefield == 0</tt></td>
24763             <td><tt>%i</tt></td>
24764           </tr>
24765           <tr>
24766             <td>for a <del>signed integral type</del><ins>signed integer
24767             type</ins></td>
24768             <td><tt>%d</tt></td>
24769           </tr>
24770           <tr>
24771             <td>for a <del>unsigned integral type</del><ins>unsigned integer
24772             type</ins></td>
24773             <td><tt>%u</tt></td>
24774           </tr>
24775         </tbody>
24776       </table>
24777     </blockquote>
24778
24779     
24780     <p>
24781       23.2 [container.requirements] table 80...
24782     </p>
24783     <blockquote>
24784       Table 89: Container requirements
24785       <table border="1">
24786         <thead>
24787           <tr>
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>
24793           </tr>
24794         </thead>
24795         <tbody>
24796           <tr>
24797             <td><tt>X::difference_type</tt></td>
24798             <td><del>signed integral type</del><ins>signed integer type</ins></td>
24799             <td>&nbsp;</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>
24803           </tr>
24804           <tr>
24805             <td><tt>X::size_type</tt></td>
24806             <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
24807             <td>&nbsp;</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>
24811           </tr>
24812         </tbody>
24813       </table>
24814     </blockquote>
24815
24816     <p>
24817       X [iterator.concepts] paragraph 1...
24818     </p>
24819     <blockquote>
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-&gt;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.
24838     </blockquote>
24839     
24840     <p>
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...
24846     </p>
24847     <blockquote>
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&lt;result_type&gt;::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 &lt; m</code> and <code>c &lt;
24857       m</code>.
24858     </blockquote>
24859     
24860     <p>
24861       Same rationale as the previous change.
24862       X [rand.adapt.xor] paragraph 6...
24863     </p>
24864     <blockquote>
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.
24871     </blockquote>
24872     
24873     <p>
24874       26.5.7.1 [rand.util.seedseq] paragraph 7...
24875     </p>
24876     <blockquote>
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&lt;RandomAccessIterator&gt;::value_type</code>
24880       shall denote an <del>unsigned integral type</del><ins>unsigned integer
24881       type</ins> capable of accomodating 32-bit quantities.  
24882     </blockquote>
24883
24884     <p>
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...
24890     </p>
24891     <blockquote>
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.
24897     </blockquote>
24898     
24899   
24900
24901
24902
24903
24904 <hr>
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>
24911 <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&lt;double&gt;</tt>.
24916 </p>
24917
24918
24919
24920 <p><b>Proposed resolution:</b></p>
24921 <ol>
24922 <li>
24923 <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
24926 </p>
24927
24928 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
24929 </pre></blockquote>
24930
24931 <p>
24932 insert
24933 </p>
24934
24935 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
24936 </pre></blockquote>
24937 </li>
24938
24939 <li>
24940 <p>
24941 Between p.4 and p.5 of the same section insert a new
24942 paragraph as part of the new member description:
24943 </p>
24944
24945 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
24946 </pre>
24947
24948 <blockquote>
24949 <i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
24950 </blockquote>
24951 </blockquote>
24952 </li>
24953 </ol>
24954
24955
24956 <p><b>Rationale:</b></p>
24957 Addressed by
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".
24959
24960
24961
24962
24963
24964 <hr>
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>
24971 <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&lt;double&gt;</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&amp;&amp;</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>.
24981 </p>
24982
24983
24984 <p><b>Proposed resolution:</b></p>
24985 <p><b>Non-concept version of the proposed resolution</b></p>
24986
24987 <ol>
24988 <li>
24989 <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
24992 </p>
24993
24994 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
24995 </pre></blockquote>
24996
24997 <p>
24998 insert
24999 </p>
25000
25001 <blockquote><pre>template&lt;typename Func&gt;
25002 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
25003 </pre></blockquote>
25004 </li>
25005
25006 <li>
25007 <p>
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:
25011 </p>
25012
25013 <blockquote><pre>template&lt;typename Func&gt;
25014 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
25015 </pre>
25016
25017 <blockquote>
25018
25019 <p>
25020 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
25021 </p>
25022
25023 <p>
25024 [p5_2] <i>Requires:</i>
25025 </p>
25026
25027 <ol type="a">
25028 <li>
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>;
25031 </li>
25032 <li>
25033 The relation <tt>0 &lt; 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;
25036 </li>
25037 <li>
25038 If <tt>nf &gt; 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> &lt; b<sub><i>k+1</i></sub></tt>.
25040 </li>
25041 </ol>
25042
25043 <p>
25044 [p5_3] <i>Effects:</i>
25045 </p>
25046
25047 <ol type="a">
25048 <li>
25049 <p>If <tt>nf == 0</tt>,</p>
25050 <ol type="a">
25051 <li>
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
25054 </li>
25055 <li>
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>.
25057 </li>
25058 </ol>
25059 </li>
25060
25061 <li>
25062 <p>Otherwise,</p>
25063 <ol type="a">
25064 <li>
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
25067 </li>
25068 <li>
25069 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
25070      calculates:</p>
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>
25074 </li>
25075 </ol>
25076 </li>
25077
25078 <li>
25079 <p>
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:
25083 </p>
25084 <blockquote><pre>&#961;<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>
25086
25087 </li>
25088 </ol>
25089
25090 </blockquote>
25091 </blockquote>
25092 </li>
25093 </ol>
25094
25095 <p><b>Concept version of the proposed resolution</b></p>
25096
25097 <ol>
25098 <li>
25099 <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
25102 </p>
25103
25104 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
25105 </pre></blockquote>
25106
25107 <p>
25108 insert
25109 </p>
25110
25111 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
25112  requires Convertible&lt;Func::result_type, double&gt;
25113 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
25114 </pre></blockquote>
25115 </li>
25116
25117 <li>
25118 <p>
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:
25122 </p>
25123
25124 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
25125  requires Convertible&lt;Func::result_type, double&gt;
25126 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
25127 </pre>
25128
25129 <blockquote>
25130
25131 <p>
25132 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
25133 </p>
25134
25135 <p>
25136 [p5_2] <i>Requires:</i>
25137 </p>
25138
25139 <ol type="a">
25140 <li>
25141 The relation <tt>0 &lt; 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;
25144 </li>
25145 <li>
25146 If <tt>nf &gt; 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> &lt; b<sub><i>k+1</i></sub></tt>.
25148 </li>
25149 </ol>
25150
25151 <p>
25152 [p5_3] <i>Effects:</i>
25153 </p>
25154
25155 <ol type="a">
25156 <li>
25157 <p>If <tt>nf == 0</tt>,</p>
25158 <ol type="a">
25159 <li>
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
25162 </li>
25163 <li>
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>.
25165 </li>
25166 </ol>
25167 </li>
25168
25169 <li>
25170 <p>Otherwise,</p>
25171 <ol type="a">
25172 <li>
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
25175 </li>
25176 <li>
25177 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
25178      calculates:</p>
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>
25182 </li>
25183 </ol>
25184 </li>
25185
25186 <li>
25187 <p>
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:
25191 </p>
25192 <blockquote><pre>&#961;<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>
25194
25195 </li>
25196 </ol>
25197
25198 </blockquote>
25199 </blockquote>
25200 </li>
25201 </ol>
25202
25203
25204
25205 <p><b>Rationale:</b></p>
25206 Addressed by
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".
25208
25209
25210
25211
25212
25213 <hr>
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>
25221        <p>
25222
25223 Recent changes to
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.
25235
25236        </p>
25237        <p>
25238
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.
25243
25244        </p>
25245        <p>
25246
25247 There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
25248 throughout the spec.
25249
25250        </p>
25251        <p>
25252
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
25257 better approach.
25258
25259        </p>
25260        <p>
25261
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.
25271
25272        </p>
25273        <p>
25274
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>:
25278
25279        </p>
25280        <blockquote>
25281            <pre>template &lt;class InputIterator, class ForwardIterator&gt;
25282 ForwardIterator
25283 uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
25284 {
25285    typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
25286
25287    ForwardIterator start = res;
25288
25289    try {
25290        for (; first != last; ++first, ++res)
25291            ::new (&amp;*res) ValueType (*first);
25292    }
25293    catch (...) {
25294        for (; start != res; --start)
25295            (&amp;*start)-&gt;~ValueType ();
25296        throw;
25297    }
25298    return res;
25299 }
25300
25301 struct SomeType {
25302    SomeType (const SomeType&amp;) <ins>throw ()</ins>;
25303 }</pre>
25304        </blockquote>
25305        <p>
25306
25307 compilers are able to emit the following efficient specialization
25308 of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
25309 (note that the <tt>catch</tt> block has been optimized away):
25310
25311        </p>
25312        <blockquote>
25313            <pre>template &lt;&gt; SomeType*
25314 uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
25315 {
25316    for (; first != last; ++first, ++res)
25317        ::new (res) SomeType (*first);
25318
25319    return res;
25320 }</pre>
25321        </blockquote>
25322        <p>
25323
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>.
25329
25330        </p>
25331        <p>
25332
25333 For example, given the following definitions of
25334 class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
25335 statements below:
25336
25337        </p>
25338        <blockquote>
25339            <pre>struct MayThrow {
25340    MayThrow ();
25341 };
25342
25343 struct WontThrow {
25344    WontThrow () <ins>throw ()</ins>;
25345 };
25346
25347 MayThrow  *a = new MayThrow [N];
25348 WontThrow *b = new WontThrow [N];</pre>
25349
25350        </blockquote>
25351        <p>
25352
25353 the compiler generates the following code for the first statement:
25354
25355        </p>
25356        <blockquote>
25357            <pre>MayThrow *a;
25358 {
25359    MayThrow *first = operator new[] (N * sizeof (*a));
25360    MayThrow *last  = first + N;
25361    MayThrow *next  = first;
25362    try {
25363        for ( ; next != last; ++next)
25364            new (next) MayThrow;
25365    }
25366    catch (...) {
25367        for ( ; first != first; --next)
25368            next-&gt;~MayThrow ();
25369        operator delete[] (first);
25370        throw;
25371    }
25372    a = first;
25373 }</pre>
25374        </blockquote>
25375        <p>
25376
25377 but it is can generate much more compact code for the second statement:
25378
25379        </p>
25380        <blockquote>
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;
25385 </pre>
25386        </blockquote>
25387        <p>
25388
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&lt;T&gt;::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.
25404
25405        </p>
25406        <p>
25407
25408 <b>Counterarguments:</b>
25409
25410        </p>
25411        <p>
25412
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.
25417
25418        </p>
25419        <p>
25420          </p><ol>
25421            <li>
25422
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.
25429
25430            </li>
25431            <li>
25432
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>
25435 or Visual
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.
25440
25441            </li>
25442            <li>
25443
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.
25449
25450            </li>
25451         </ol>
25452        <p></p>
25453        <p>
25454
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>.
25470
25471        </p>
25472        <p>
25473
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.
25484
25485        </p>
25486        <p>
25487
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>
25493 Nothing." clause.
25494
25495       </p>
25496
25497 <p><i>[
25498 2009-07 Frankfurt
25499 ]</i></p>
25500
25501
25502 <blockquote>
25503 <p>
25504 We need someone to do an extensive review.
25505 </p>
25506 <p>
25507 NAD Future.
25508 </p>
25509 </blockquote>
25510
25511    
25512    <p><b>Proposed resolution:</b></p>
25513        <p>
25514
25515 We propose two possible solutions. Our recommendation is to adopt
25516 Option 1 below.
25517
25518        </p>
25519        <p>
25520
25521 <b>Option 1:</b>
25522
25523        </p>
25524        <p>
25525
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."
25532
25533        </p>
25534        <p>
25535
25536 <b>Option 2:</b>
25537
25538        </p>
25539        <p>
25540
25541 For consistency, replace all occurrences of the empty exception
25542 specification with a "<i>Throws:</i> Nothing." clause.
25543
25544        </p>
25545    
25546
25547
25548
25549 <hr>
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>
25557 <p>
25558 The <tt>atomic_address</tt> type and <tt>atomic&lt;T*&gt;</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.
25562 </p>
25563
25564 <p><i>[
25565 Summit:
25566 ]</i></p>
25567
25568 <blockquote>
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
25571 include all cases.
25572 </blockquote>
25573
25574 <p><i>[
25575 2009-07 Frankfurt
25576 ]</i></p>
25577
25578
25579 <blockquote>
25580 <p>
25581 Lawrence will handle all issues relating to atomics in a single paper.
25582 </p>
25583 <p>
25584 LWG will defer discussion on atomics until that paper appears.
25585 </p>
25586 <p>
25587 Move to Open.
25588 </p>
25589 </blockquote>
25590
25591 <p><i>[
25592 2009-08-17 Handled by
25593 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25594 ]</i></p>
25595
25596
25597 <p><i>[
25598 2009-10 Santa Cruz:
25599 ]</i></p>
25600
25601
25602 <blockquote>
25603 NAD Editorial.  Solved by
25604 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25605 </blockquote>
25606
25607
25608
25609 <p><b>Proposed resolution:</b></p>
25610 <p>
25611 Add const qualification to the pointer values of the <tt>atomic_address</tt>
25612 and <tt>atomic&lt;T*&gt;</tt> specializations.  E.g.
25613 </p>
25614
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*&amp;, <ins>const</ins> void*,
25619                           memory_order, memory_order) volatile;
25620    bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
25621                           memory_order = memory_order_seq_cst ) volatile;
25622    void* operator=(<ins>const</ins> void*) volatile;
25623 } atomic_address;
25624
25625 void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
25626 void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
25627                           memory_order);
25628 void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
25629 void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
25630                               memory_order);
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>
25637
25638
25639
25640
25641
25642 <hr>
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>
25651 <p>
25652 The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
25653 be inconsistently missing parameters.
25654 </p>
25655
25656 <p><i>[
25657 Post Summit:
25658 ]</i></p>
25659
25660
25661 <blockquote>
25662 <p>
25663 Lawrence: Need to write up a list for Pete with details.
25664 </p>
25665 <p>
25666 Detlef: Should not be New, we already talked about in Concurrency group.
25667 </p>
25668 <p>
25669 Recommend Open.
25670 </p>
25671 </blockquote>
25672
25673 <p><i>[
25674 2009-07 Frankfurt
25675 ]</i></p>
25676
25677
25678 <blockquote>
25679 <p>
25680 Lawrence will handle all issues relating to atomics in a single paper.
25681 </p>
25682 <p>
25683 LWG will defer discussion on atomics until that paper appears.
25684 </p>
25685 <p>
25686 Move to Open.
25687 </p>
25688 </blockquote>
25689
25690 <p><i>[
25691 2009-08-17 Handled by
25692 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25693 ]</i></p>
25694
25695
25696 <p><i>[
25697 2009-10 Santa Cruz:
25698 ]</i></p>
25699
25700
25701 <blockquote>
25702 NAD Editorial.  Solved by
25703 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25704 </blockquote>
25705
25706
25707
25708 <p><b>Proposed resolution:</b></p>
25709 <p>
25710 Add the appropriate parameters.  For example,
25711 </p>
25712
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>
25716
25717
25718
25719
25720
25721 <hr>
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>
25728 <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.
25733 </p>
25734
25735 <p><i>[
25736 San Francisco:
25737 ]</i></p>
25738
25739
25740 <blockquote>
25741 <p>
25742 Howard recommends NAD with the following explanation:
25743 </p>
25744
25745 <p>
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.
25750 For example:
25751 </p>
25752
25753 <blockquote><pre>template &lt;class Duration&gt;
25754 bool
25755 condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
25756                                const chrono::time_point&lt;chrono::system_clock, Duration&gt;&amp; abs_time)
25757 {
25758     using namespace chrono;
25759     nanoseconds d = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch());
25760     __do_timed_wait(lock.mutex()-&gt;native_handle(), time_point&lt;system_clock, nanoseconds&gt;(d));
25761     return system_clock::now() &lt; abs_time;
25762 }
25763
25764 template &lt;class Clock, class Duration&gt;
25765 bool
25766 condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
25767                                const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)
25768 {
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&lt;nanoseconds&gt;(abs_time.time_since_epoch() -
25773                                               c_entry.time_since_epoch());
25774     __do_timed_wait(lock.mutex()-&gt;native_handle(), s_entry + dn);
25775     return Clock::now() &lt; abs_time;
25776 }
25777 </pre></blockquote>
25778
25779 <p>
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.
25785 </p>
25786
25787 <p>
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.
25791 </p>
25792
25793 <p>
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).
25801 </p>
25802 </blockquote>
25803
25804 <p><i>[
25805 Post Summit:
25806 ]</i></p>
25807
25808
25809 <blockquote>
25810 <p>
25811 "POSIX people will review the proposed NAD resolution at their upcoming NY
25812 meeting.
25813 </p>
25814
25815 <p>
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>.
25817 </p>
25818 </blockquote>
25819
25820 <p><i>[
25821 2009-07 Frankfurt
25822 ]</i></p>
25823
25824
25825 <blockquote>
25826 Move to NAD.
25827 </blockquote>
25828
25829 <p><i>[
25830 2009-07-18 Detlef reopens the issue:
25831 ]</i></p>
25832
25833
25834 <blockquote>
25835 <p>
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):
25842 </p>
25843 <p>
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.
25847 </p>
25848
25849 <p>
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.
25853 </p>
25854
25855 <p>
25856 Sorry that I didn't remember this on Friday, but it was Friday
25857 afternoon after a busy week...
25858 </p>
25859
25860 <p>
25861 So as the decision was made on a wrong asumption, I propose to re-open
25862 the issue.
25863 </p>
25864 </blockquote>
25865
25866 <p><i>[
25867 2009-07-26 Howard adds:
25868 ]</i></p>
25869
25870
25871 <blockquote>
25872 <p>
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
25876 on POSIX.
25877 </p>
25878
25879 <p>
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>.
25887 </p>
25888
25889 <blockquote>
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
25895 of the call.
25896 </blockquote>
25897
25898 <p>
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.
25901 </p>
25902
25903 <p>
25904 Might this simply be an oversight, or minor defect in the POSIX specification?
25905 </p>
25906
25907 <p>
25908 I do not believe so.  This same section goes on to say in <em>non-normative</em>
25909 text:
25910 </p>
25911
25912 <blockquote>
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.
25916 </blockquote>
25917
25918 <p>
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>. 
25926 </p>
25927
25928 <p>
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>
25934 always returns:
25935 </p>
25936
25937 <blockquote><pre><tt>Clock::now() &lt; abs_time</tt>
25938 </pre></blockquote>
25939
25940 <p>
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
25947 here.
25948 </p>
25949
25950 <p>
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.
25956 </p>
25957
25958 <p>
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.
25963 </p>
25964
25965 <p>
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.
25969 </p>
25970
25971 </blockquote>
25972
25973 <p><i>[
25974 2009-09-30: See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2969.html">N2969</a>.
25975 ]</i></p>
25976
25977
25978 <p><i>[
25979 2009-10 Santa Cruz:
25980 ]</i></p>
25981
25982
25983 <blockquote>
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>.
25987 </blockquote>
25988
25989 <p><i>[
25990 2010-02-11 Anthony provided wording.
25991 ]</i></p>
25992
25993
25994 <p><i>[
25995 2010-02-22 Anthony adds:
25996 ]</i></p>
25997
25998
25999 <blockquote>
26000 <p>
26001 I am strongly against
26002 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html">N2999</a>.
26003 </p>
26004
26005 <p>
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.
26011 </p>
26012
26013 <p>
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
26016 clock.
26017 </p>
26018
26019 <p>
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.
26025 </p>
26026
26027 <p>
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.
26033 </p>
26034
26035 <p>
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.
26039 </p>
26040
26041 <p>
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>.
26047 </p>
26048
26049 <p>
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.
26054 </p>
26055
26056 <p>
26057 My preferred resolution to issue 887 is currently the PR in the issues list.
26058 </p>
26059 </blockquote>
26060
26061 <p><i>[
26062 2010 Pittsburgh:
26063 ]</i></p>
26064
26065
26066 <blockquote>
26067 <p>
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>
26070 into the WP.
26071 </p>
26072 <p>
26073 There was support for moving this issue as proposed to Ready, but the support
26074 was insufficient to call a consensus.
26075 </p>
26076 <p>
26077 There was consensus for moving this issue to NAD as opposed to leaving it open.
26078 Rationale added.
26079 </p>
26080 </blockquote>
26081
26082
26083
26084 <p><b>Rationale:</b></p>
26085 <p>
26086 The standard as written is sufficiently implementable and self consistent.
26087 </p>
26088
26089
26090 <p><b>Proposed resolution:</b></p>
26091 <p>
26092 Add a new paragraph after 30.2.4 [thread.req.timing]p3:
26093 </p>
26094
26095 <blockquote>
26096 <p>
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>.
26100 </p>
26101
26102 <p><ins>
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
26108 note</i>]
26109 </ins></p>
26110 </blockquote>
26111
26112
26113
26114
26115
26116 <hr>
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>
26123
26124 <p><b>Addresses UK 324</b></p>
26125
26126 <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.
26130 </p>
26131
26132 <p><i>[
26133 San Francisco:
26134 ]</i></p>
26135
26136
26137 <blockquote>
26138 <p>
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.
26142 </p>
26143 <p>
26144 Group expresses support for putting ids in both unordered and ordered containers.
26145 </p>
26146 </blockquote>
26147
26148 <p><i>[
26149 post San Francisco:
26150 ]</i></p>
26151
26152
26153 <blockquote>
26154 <p>
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&lt;thread::id&gt;</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
26160 (again). :-)
26161 </p>
26162 <p>
26163 Recommend NAD.
26164 </p>
26165
26166 </blockquote>
26167
26168 <p><i>[
26169 Post Summit:
26170 ]</i></p>
26171
26172
26173 <blockquote>
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.
26176 </blockquote>
26177
26178 <p><i>[
26179 Post Summit, Alisdair adds:
26180 ]</i></p>
26181
26182
26183 <blockquote>
26184 <p>
26185 The recommendation for LWG-889/UK-324 is NAD, already specified.
26186 </p>
26187 <p>
26188 It is not clear to me that the specification is complete.
26189 </p>
26190 <p>
26191 In particular, the synopsis of <tt>&lt;functional&gt;</tt> in 20.8 [function.objects] does not mention <tt>hash&lt; thread::id
26192 &gt;</tt> nor <tt>hash&lt; error_code &gt;</tt>, although their
26193 existence is implied by 20.8.15 [unord.hash], p1.
26194 </p>
26195 <p>
26196 I am fairly uncomfortable putting the declaration for the
26197 <tt>thread_id</tt> specialization into <tt>&lt;functional&gt;</tt> as
26198 <tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
26199 that <tt>&lt;functional&gt;</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.
26202 </p>
26203 <p>
26204 It seems better to me that the dependency goes the other way around
26205 (<tt>&lt;thread&gt;</tt> will more typically make use of
26206 <tt>&lt;functional&gt;</tt> than vice-versa) and the
26207 <tt>hash&lt;thread::id&gt;</tt> specialization be declared in the
26208 <tt>&lt;thread&gt;</tt> header.
26209 </p>
26210 <p>
26211 I think <tt>hash&lt;error_code&gt;</tt> could go into either
26212 <tt>&lt;system_error&gt;</tt> or <tt>&lt;functional&gt;</tt> and have no
26213 immediate preference either way.  However, it should clearly appear in
26214 the synopsis of one of these two.
26215 </p>
26216 <p>
26217 Recommend moving 889 back to open, and tying in a reference to UK-324.
26218 </p>
26219 </blockquote>
26220
26221 <p><i>[
26222 Batavia (2009-05):
26223 ]</i></p>
26224
26225 <blockquote>
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.
26228 </blockquote>
26229
26230 <p><i>[
26231 2009-05-24 Alisdair adds:
26232 ]</i></p>
26233
26234 <blockquote>
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.
26239 </blockquote>
26240
26241 <p><i>[
26242 2009-07 Frankfurt
26243 ]</i></p>
26244
26245
26246 <blockquote>
26247 Decided we want to move hash specialization for thread_id to the thread
26248 header. Alisdair to provide wording.
26249 </blockquote>
26250
26251 <p><i>[
26252 2009-07-28 Alisdair provided wording, moved to Review.
26253 ]</i></p>
26254
26255
26256 <p><i>[
26257 2009-10 Santa Cruz:
26258 ]</i></p>
26259
26260
26261 <blockquote>
26262 Add a strike for <tt>hash&lt;thread::id&gt;</tt>. Move to Ready
26263 </blockquote>
26264
26265 <p><i>[
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.
26268 ]</i></p>
26269
26270
26271 <p><i>[
26272 2010-02-09 Moved from Ready to Open:
26273 ]</i></p>
26274
26275
26276 <blockquote>
26277 <p>
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:
26280 </p>
26281
26282 <blockquote>
26283 hash template specialization allows <tt>thread::id</tt> objects to be used as keys in
26284 unordered containers.
26285 </blockquote>
26286
26287 <p>
26288 should be added to the WP.
26289 </p>
26290
26291
26292 </blockquote>
26293
26294 <p><i>[
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.
26296 ]</i></p>
26297
26298
26299
26300
26301 <p><b>Rationale:</b></p>
26302 <p>
26303 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
26304 </p>
26305
26306
26307 <p><b>Proposed resolution:</b></p>
26308
26309 <p>
26310 Remove the following prototype from the synopsis in
26311 20.8 [function.objects]:
26312 </p>
26313
26314 <blockquote><pre><del>
26315 template &lt;&gt; struct hash&lt;std::thread::id&gt;;
26316 </del></pre></blockquote>
26317
26318 <p>
26319 Add to 30.3 [thread.threads], p1 Header <tt>&lt;thread&gt;</tt> synopsis:
26320 </p>
26321
26322 <blockquote><pre><ins>template &lt;class T&gt; struct hash;
26323 template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
26324 </pre></blockquote>
26325
26326 <p>
26327 Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
26328 </p>
26329
26330 <blockquote><pre><ins>template &lt;&gt;
26331 struct hash&lt;thread::id&gt; : public unary_function&lt;thread::id, size_t&gt; {
26332    size_t operator()(thread::id val) const;
26333 };</ins>
26334 </pre></blockquote>
26335
26336 <p>
26337 Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
26338 </p>
26339
26340 <blockquote>
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>]
26346 </blockquote>
26347
26348 <p>
26349 Add new paragraph to end of 30.3.1.1 [thread.thread.id]
26350 </p>
26351
26352 <blockquote><pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
26353 </pre>
26354 <blockquote><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>
26358 </blockquote>
26359
26360
26361
26362
26363
26364 <hr>
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>
26371 <p>
26372 I was looking at the latest draft on <tt>forward_list</tt>.  Especially the splice methods.
26373 </p>
26374 <p>
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
26377 change:
26378 </p>
26379 <blockquote>
26380 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
26381 </blockquote>
26382
26383 <p>
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>.
26391 </p>
26392 <p>
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 ...
26395 </p>
26396 <p>
26397 Unless I'm misconceiving the whole thing.  Which is possible.  I'll look at it again.
26398 </p>
26399 <p>
26400 I'm pretty sure about the first part though.
26401 </p>
26402
26403 <p><i>[
26404 San Francisco:
26405 ]</i></p>
26406
26407
26408 <blockquote>
26409 <p>
26410 This issue is more complicated than it looks.
26411 </p>
26412 <p>
26413 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
26414 </p>
26415 <p>
26416 add a statement after paragraph 48 that complexity is O(1)
26417 </p>
26418 <p>
26419 remove the complexity statement from the first overload of splice_after
26420 </p>
26421 <p>
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
26424 dereferenceable?
26425 </p>
26426 <p>
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.
26430 </p>
26431 <p>
26432 Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>.
26433 </p>
26434 </blockquote>
26435
26436
26437 <p><b>Proposed resolution:</b></p>
26438 <p>
26439 In 23.3.3.5 [forwardlist.ops] paragraph 40
26440 change:
26441 </p>
26442 <blockquote>
26443 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
26444 </blockquote>
26445
26446
26447
26448
26449
26450 <hr>
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>
26458 <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>.
26462 </p>
26463
26464 <p><i>[
26465 2009-07 Frankfurt
26466 ]</i></p>
26467
26468
26469 <blockquote>
26470  Alan to address in paper.
26471 </blockquote>
26472
26473
26474
26475 <p><b>Proposed resolution:</b></p>
26476 <p>
26477 </p>
26478
26479
26480
26481
26482
26483 <hr>
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>
26490 <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.
26492 </p>
26493
26494 <p><i>[
26495 San Francisco:
26496 ]</i></p>
26497
26498
26499 <blockquote>
26500 <p>
26501 This issue is more complicated than it looks.
26502 </p>
26503 <p>
26504 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
26505 </p>
26506 <p>
26507 add a statement after paragraph 48 that complexity is O(1)
26508 </p>
26509 <p>
26510 remove the complexity statement from the first overload of splice_after
26511 </p>
26512 <p>
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
26515 dereferenceable?
26516 </p>
26517 </blockquote>
26518
26519 <p>
26520 There are actually 3 issues here:
26521 </p>
26522
26523 <ol>
26524 <li>
26525 <p>
26526 What value should <tt>erase_after</tt> return?  With <tt>list</tt>, code often
26527 looks like:
26528 </p>
26529 <blockquote><pre>for (auto i = l.begin(); i != l.end();)
26530 {
26531     // inspect *i and decide if you want to erase it
26532     // ...
26533     if (I want to erase *i)
26534         i = l.erase(i);
26535     else
26536         ++i;
26537 }
26538 </pre></blockquote>
26539 <p>
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:
26543 </p>
26544 <blockquote><pre>auto i = fl.before_begin();
26545 auto ip1 = i;
26546 for (++ip1; ip1 != fl.end(); ++ip1)
26547 {
26548     // inspect *(i+1) and decide if you want to erase it
26549     // ...
26550     if (I want to erase *(i+1))
26551         i = fl.erase_after(i);
26552     else
26553         ++i;
26554     ip1 = i;
26555 }
26556 </pre></blockquote>
26557 <p>
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).
26561 </p>
26562 <p>
26563 Existing practice:
26564 </p>
26565 <ul>
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>
26568 </ul>
26569 <p>
26570 There is not a strong technical argument for either solution over the other.
26571 </p>
26572 </li>
26573
26574 <li>
26575 <p>
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>.
26578 </p>
26579 <p>
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>.
26582 </p>
26583 <p>
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). 
26589 </p>
26590 <p>
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>.
26598 </p>
26599 <p>
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
26602 enables:
26603 </p>
26604 <blockquote><pre>x.erase_after(pos, x.end());
26605 </pre></blockquote>
26606
26607 <p>
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:
26610 </p>
26611
26612 <blockquote><pre>iterator erase_to_end(const_iterator position);
26613 </pre></blockquote>
26614
26615 <p>
26616 to compensate.
26617 </p>
26618
26619 <p>
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.
26624 </p>
26625
26626 </li>
26627
26628 <li>
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>&#927;</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>&#927;</i>(1).
26639 </li>
26640 </ol>
26641
26642 <p><i>[
26643 Batavia (2009-05):
26644 ]</i></p>
26645
26646 <blockquote>
26647 <p>
26648 We agree with the proposed resolution.
26649 </p>
26650 <p>
26651 Move to Review.
26652 </p>
26653 </blockquote>
26654
26655 <p><i>[
26656 2009-07 Frankfurt
26657 ]</i></p>
26658
26659
26660 <blockquote>
26661 <p>
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)
26665 </p>
26666 <p>
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)
26670 </p>
26671 <p>
26672 Alan suggested removing the "foward_last&lt;T. Alloc&gt;&amp;&amp; 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").
26676 </p>
26677 <p>
26678 We prefer to keep <tt>x</tt>.
26679 </p>
26680 <p>
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.
26685 </p>
26686 <p>
26687 Alan to write a non-normative comment to explain the use of fully-closed ranges.
26688 </p>
26689 <p>
26690 Move to Ready, with the changes described above. (Howard: awaiting note from Alan)
26691 </p>
26692 </blockquote>
26693
26694 <p><i>[
26695 2009-10 Santa Cruz:
26696 ]</i></p>
26697
26698
26699 <blockquote>
26700 NAD Editorial, addressed by
26701 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2988.pdf">N2988</a>.
26702 </blockquote>
26703
26704
26705
26706 <p><b>Proposed resolution:</b></p>
26707 <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.
26710 </p>
26711
26712 <p>
26713 Change 23.3.3.4 [forwardlist.modifiers]:
26714 </p>
26715
26716 <blockquote>
26717 <pre>iterator erase_after(const_iterator position);
26718 </pre>
26719 <blockquote>
26720 <p>
26721 <i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
26722 </p>
26723 <p>
26724 <i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
26725 </p>
26726 <p>
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>.
26730 </p>
26731 </blockquote>
26732
26733
26734 <pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
26735 </pre>
26736 <blockquote>
26737 <p>
26738 <i>Requires:</i> All iterators in the range
26739 <tt><del>[</del><ins>(</ins>position,last)</tt>
26740 are dereferenceable.
26741 </p>
26742 <p>
26743 <i>Effects:</i> Erases the elements in the range
26744 <tt><del>[</del><ins>(</ins>position,last)</tt>.
26745 </p>
26746 <p>
26747 <i>Returns:</i>  <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
26748 </p>
26749 </blockquote>
26750 </blockquote>
26751
26752 <p>
26753 Change 23.3.3.5 [forwardlist.ops]:
26754 </p>
26755
26756 <blockquote>
26757 <pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x);
26758 </pre>
26759 <blockquote>
26760 <p>
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>&amp;x != this</tt>.
26763 </p>
26764 <p>
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>. 
26770 </p>
26771 <p>
26772 <i>Throws:</i> Nothing. 
26773 </p>
26774 <p>
26775 <i>Complexity:</i> <del><i>&#927;</i>(1)</del> <ins><i>&#927;</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
26776 </p>
26777 </blockquote>
26778
26779 <p>...</p>
26780
26781 <pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x, 
26782                   const_iterator first, const_iterator last);
26783 </pre>
26784 <blockquote>
26785 <p>
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>.
26792 </p>
26793 <p>
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
26800 <tt>x</tt>.
26801 </p>
26802 <p>
26803 <ins><i>Complexity:</i> <i>&#927;</i>(1).</ins>
26804 </p>
26805 </blockquote>
26806
26807 </blockquote>
26808
26809
26810
26811
26812
26813
26814 <hr>
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>
26821
26822 <p>
26823 The requires clause on the <tt>const T &amp;</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.
26826 </p>
26827 <p>
26828 Suggested resolutions are:
26829 </p>
26830 <ol type="a">
26831 <li>
26832 Add another overload with a negative constraint on copy-constructible
26833 and flag it "= delete".
26834 </li>
26835 <li>
26836 Drop the copy-constructible overload entirely and rely on perfect
26837 forwarding to catch move issues one level deeper.
26838 </li>
26839 <li>
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.
26843 </li>
26844 </ol>
26845
26846 <p><i>[
26847 Post Summit, Alisdair adds:
26848 ]</i></p>
26849
26850
26851 <blockquote>
26852 <p>
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.
26856 </p>
26857
26858 <p>
26859 Suggest resolve as NAD Editorial with a reference to the paper.
26860 </p>
26861 </blockquote>
26862
26863 <p><i>[
26864 Batavia (2009-05):
26865 ]</i></p>
26866
26867 <blockquote>
26868 We agree that this has been resolved in the latest Working Draft.
26869 Move to NAD.
26870 </blockquote>
26871
26872
26873 <p><b>Proposed resolution:</b></p>
26874 <p>
26875 Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
26876 </p>
26877
26878
26879
26880
26881
26882 <hr>
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>
26889
26890 <p><b>Addresses FR 32 and DE 16</b></p>
26891
26892 <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.
26897 </p>
26898
26899 <p>FR 32:</p>
26900
26901 <blockquote>
26902 The definition of <tt>numeric_limits&lt;&gt;</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
26908 type theory.
26909 </blockquote>
26910
26911 <p>DE 16:</p>
26912
26913 <blockquote>
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.
26918 </blockquote>
26919
26920 <p><i>[
26921 Summit:
26922 ]</i></p>
26923
26924
26925 <blockquote>
26926 Move to Open.  Alisdair and Gaby will work on a solution, along with the new
26927 treatment of axioms in clause 14.
26928 </blockquote>
26929
26930
26931
26932 <p><b>Proposed resolution:</b></p>
26933 <p>
26934 </p>
26935
26936
26937
26938
26939
26940 <hr>
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>
26946 <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.
26950 </p>
26951
26952 <p><i>[
26953 Post Summit Daniel adds:
26954 ]</i></p>
26955
26956
26957 <blockquote>
26958 <p>
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.
26961 </p>
26962 </blockquote>
26963
26964 <p><i>[
26965 Batavia (2009-05):
26966 ]</i></p>
26967
26968 <blockquote>
26969 <p>
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.
26973 </p>
26974 <p>
26975 Move to NAD.
26976 </p>
26977 </blockquote>
26978
26979 <p><i>[
26980 2009-05-25 Daniel adds:
26981 ]</i></p>
26982
26983
26984 <ol>
26985 <li>
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.
26987 </li>
26988 <li>
26989 To support backward compatibility a second overload of <tt>operator*</tt>
26990 can be added.
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
26993 qualification and
26994 to properly reflect the dual nature of built-in <tt>operator*</tt> as of
26995 13.5.8 [over.literal]/6.
26996 </li>
26997 </ol>
26998
26999
27000 <p><b>Proposed resolution:</b></p>
27001
27002
27003
27004
27005
27006 <hr>
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>
27014 <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>:
27017 </p>
27018 <p>
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?
27024 </p>
27025 <p>
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
27028 </p>
27029 <blockquote>
27030 <p>
27031 The behavior of a program is undefined if:
27032 </p>
27033 <ul>
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>
27037 </ul>
27038 </blockquote>
27039
27040 <p>
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.
27044 </p>
27045 <p>
27046 A potential addition to the list would be
27047 </p>
27048 <ul>
27049 <li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li>
27050 </ul>
27051 <p>
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?
27055 </p>
27056
27057 <p><i>[
27058 Summit:
27059 ]</i></p>
27060
27061
27062 <blockquote>
27063 <p>
27064 Two resolutions: "not a defect" and "duplicate", as follows:
27065 </p>
27066 <ul>
27067 <li>
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.
27071 </li>
27072 <li>
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>.
27074 </li>
27075 <li>
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
27078 Precondition.
27079 </li>
27080 </ul>
27081 </blockquote>
27082
27083
27084 <p><b>Proposed resolution:</b></p>
27085
27086
27087
27088
27089
27090
27091 <hr>
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>
27097 <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:
27102 </p>
27103 <p>
27104 8.5.4 [dcl.init.list]/4:
27105 </p>
27106 <blockquote>
27107 When an initializer list is implicitly converted to a
27108 <tt>std::initializer_list&lt;E&gt;</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.[..]
27111 </blockquote>
27112
27113 <p>
27114 18.9 [support.initlist]/2.
27115 </p>
27116
27117 <blockquote>
27118 An object of type <tt>initializer_list&lt;E&gt;</tt> provides access to an array of
27119 objects of type <tt>const E</tt>.[..]
27120 </blockquote>
27121
27122 <p>
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:
27127 </p>
27128
27129 <blockquote><pre>// Header A: (Should concept-check even in stand-alone modus)
27130
27131 template &lt;DefaultConstructible T&gt;
27132 requires MoveConstructible&lt;T&gt;
27133 void generate_and_do_3(T a) {
27134   std::initializer_list&lt;T&gt; list{T(), std::move(a), T()};
27135   ...
27136 }
27137
27138 void do_more();
27139 void do_more_or_less();
27140
27141 template &lt;DefaultConstructible T&gt;
27142 requires MoveConstructible&lt;T&gt;
27143 void more_generate_3() {
27144   do_more();
27145   generate_and_do_3(T());
27146 }
27147
27148 template &lt;DefaultConstructible T&gt;
27149 requires MoveConstructible&lt;T&gt;
27150 void something_and_generate_3() {
27151   do_more_or_less();
27152   more_generate_3();
27153 }
27154
27155 // Test.cpp
27156
27157 #include "A.h"
27158
27159 class Abstract {
27160 public:
27161   virtual ~Abstract();
27162   virtual void foo() = 0; // abstract type
27163   Abstract(Abstract&amp;&amp;){} // MoveConstructible
27164   Abstract(){} // DefaultConstructible
27165 };
27166
27167 int main() {
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&lt;Abstract&gt;();
27172 }
27173 </pre></blockquote>
27174
27175 <p>
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>:
27181 </p>
27182
27183 <blockquote><pre>template&lt;ObjectType T&gt;
27184 class ExtContainer {
27185 public:
27186   requires ValueType&lt;T&gt;
27187   ExtContainer(std::initializer_list&lt;T&gt;);
27188   ...
27189 };
27190 </pre></blockquote>
27191
27192 <p><i>[
27193 Batavia (2009-05):
27194 ]</i></p>
27195
27196 <blockquote>
27197 Move to Tentatively Ready.
27198 </blockquote>
27199
27200 <p><i>[
27201 2009-07 Frankfurt:
27202 ]</i></p>
27203
27204
27205 <blockquote>
27206 Need to look at again without concepts.
27207 </blockquote>
27208
27209
27210
27211 <p><b>Proposed resolution:</b></p>
27212 <ol>
27213 <li>
27214 In 18.9 [support.initlist]/p.1 replace in "header <tt>&lt;initializer_list&gt;</tt> synopsis"
27215 the constraint "<tt>ObjectType</tt>" in the template parameter list by the
27216 constraint "<tt>ValueType</tt>".
27217 </li>
27218 </ol>
27219
27220
27221
27222
27223
27224
27225 <hr>
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>
27232
27233 <p><b>Addresses US 90</b></p>
27234
27235 <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.
27239 </p>
27240 <blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
27241 atomic_bool&amp; operator=(bool) volatile;
27242 </pre></blockquote>
27243
27244 <p>
27245 This leads to ambiguity when assigning a non-atomic value to a
27246 non-volatile instance of an atomic type:
27247 </p>
27248 <blockquote><pre>atomic_bool b;
27249 b=false;
27250 </pre></blockquote>
27251
27252 <p>
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>.
27258 </p>
27259
27260 <p>
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.
27262 </p>
27263
27264 <p><i>[
27265 Summit:
27266 ]</i></p>
27267
27268 <blockquote>
27269 Move to open. Assign to Lawrence. Related to US 90 comment.
27270 </blockquote>
27271
27272 <p><i>[
27273 2009-08-17 Handled by
27274 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
27275 ]</i></p>
27276
27277
27278 <p><i>[
27279 2009-10 Santa Cruz:
27280 ]</i></p>
27281
27282
27283 <blockquote>
27284 NAD Editorial.  Solved by
27285 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
27286 </blockquote>
27287
27288
27289
27290 <p><b>Proposed resolution:</b></p>
27291 <p>
27292 Add volatile qualification to the deleted copy-assignment operator of
27293 all the atomic types:
27294 </p>
27295
27296 <blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) <ins>volatile</ins> = delete;
27297 atomic_itype&amp; operator=(atomic_itype const&amp;) <ins>volatile</ins> = delete;
27298 </pre></blockquote>
27299
27300 <p>
27301 etc.
27302 </p>
27303 <p>
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>.
27307 </p>
27308
27309
27310
27311
27312
27313 <hr>
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>
27321
27322 <p>
27323 The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
27324 concept, given in paragraph 7 is:
27325 </p>
27326
27327 <blockquote><pre>result_type  T::operator=(T&amp;&amp;  rv);  // inherited from HasAssign&lt;T, T&amp;&amp;&gt;
27328 </pre>
27329
27330 <blockquote>
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>]
27334 </blockquote>
27335 </blockquote>
27336
27337 <p>
27338 The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
27339 probably due to a cut&amp;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.
27351 </p>
27352
27353 <p><i>[
27354 2009-05-09 Alisdair adds:
27355 ]</i></p>
27356
27357
27358 <blockquote>
27359 <p>
27360 Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
27361 </p>
27362 <p>
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
27368 made by that type.
27369 </p>
27370 </blockquote>
27371
27372 <p><i>[
27373 2009-05-09 Howard adds:
27374 ]</i></p>
27375
27376
27377 <blockquote>
27378 <p>
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.
27386 </p>
27387
27388 <p>
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.
27392 </p>
27393
27394 <p>
27395 Here is user-written code which must be allowed to be legal:
27396 </p>
27397 <blockquote><pre>#include &lt;vector&gt;
27398 #include &lt;cstdio&gt;
27399
27400 template &lt;class Allocator&gt;
27401 void
27402 inspect(std::vector&lt;double, Allocator&gt;&amp;&amp; v)
27403 {
27404     std::vector&lt;double, Allocator&gt; 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&lt;double, Allocator&gt;::iterator I;
27408     for (I i = v.begin(), e = v.end(); i != e; ++i)
27409         printf("%f\n", *i);
27410 }
27411
27412 int main()
27413 {
27414     std::vector&lt;double&gt; v1(100, 5.5);
27415     inspect(move(v1));
27416 }
27417 </pre></blockquote>
27418
27419 <p>
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.
27422 </p>
27423 <p>
27424 I believe the current proposed wording is consistent with my view on this.
27425 </p>
27426 </blockquote>
27427
27428 <p><i>[
27429 Batavia (2009-05):
27430 ]</i></p>
27431
27432 <blockquote>
27433 We agree that the proposed resolution
27434 is an improvement over the current wording.
27435 </blockquote>
27436
27437 <p><i>[
27438 2009-07 Frankfurt:
27439 ]</i></p>
27440
27441
27442 <blockquote>
27443 Need to look at again without concepts.
27444 </blockquote>
27445
27446 <p><i>[
27447 2009-07 Frankfurt:
27448 ]</i></p>
27449
27450
27451 <blockquote>
27452 Walter will consult with Dave and Doug.
27453 </blockquote>
27454
27455 <p><i>[
27456 2009-10 Santa Cruz:
27457 ]</i></p>
27458
27459
27460 <blockquote>
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.
27463 </blockquote>
27464
27465 <p><i>[
27466 2010-01-23 Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
27467 Rationale added below.
27468 ]</i></p>
27469
27470
27471
27472 <p><b>Rationale:</b></p>
27473 <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
27476 assignment.
27477 </p>
27478
27479
27480 <p><b>Proposed resolution:</b></p>
27481 <p>
27482 In  [concept.copymove], replace the postcondition in paragraph 7 with:
27483 </p>
27484
27485 <blockquote>
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>]
27492 </blockquote>
27493
27494
27495
27496
27497
27498 <hr>
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>
27505 <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.
27508 </p>
27509
27510 <p><i>[
27511 Post Summit Daniel adds:
27512 ]</i></p>
27513
27514
27515 <blockquote>
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>.
27518 </blockquote>
27519
27520 <p><i>[
27521 Batavia (2009-05):
27522 ]</i></p>
27523
27524 <blockquote>
27525 Move to NAD; the changes have already been made.
27526 </blockquote>
27527
27528
27529 <p><b>Proposed resolution:</b></p>
27530 <p>
27531 Replace in 25.3.3 [alg.swap] before p. 3 until p. 4 by
27532 </p>
27533
27534 <blockquote><pre>template &lt;<del>class</del> <ins>ValueType</ins> T, size_t N&gt;
27535 <ins>requires Swappable&lt;T&gt;</ins>
27536 void swap(T (&amp;a)[N], T (&amp;b)[N]);
27537 </pre>
27538 <blockquote>
27539 <p>
27540 <del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del>
27541 </p>
27542 <p>
27543 <i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt>
27544 </p>
27545 </blockquote>
27546 </blockquote>
27547
27548
27549
27550
27551
27552
27553 <hr>
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>
27560 <p>
27561 (A) 25.3.5 [alg.replace]/1:
27562 </p>
27563
27564 <blockquote>
27565 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.
27566 </blockquote>
27567
27568 <p>
27569 (B) 25.3.5 [alg.replace]/4:
27570 </p>
27571
27572 <blockquote>
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.[..]
27575 </blockquote>
27576
27577 <p>
27578 Since conceptualization, the quoted content of these clauses is covered
27579 by the existing requirements
27580 </p>
27581
27582 <p>
27583 (A) <tt>OutputIterator&lt;Iter, const T&amp;&gt;</tt>
27584 </p>
27585
27586 <p>
27587 and
27588 </p>
27589
27590 <p>
27591 (B) <tt>OutputIterator&lt;OutIter, InIter::reference&gt; &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt;</tt>
27592 </p>
27593
27594 <p>
27595 resp, and thus should be removed.
27596 </p>
27597
27598 <p><i>[
27599 Batavia (2009-05):
27600 ]</i></p>
27601
27602 <blockquote>
27603 <p>
27604 We agree with the proposed resolution.
27605 </p>
27606 <p>
27607 Move to Tentatively Ready.
27608 </p>
27609 </blockquote>
27610
27611
27612 <p><b>Proposed resolution:</b></p>
27613 <ol type="A">
27614 <li>
27615 <p>
27616 Remove 25.3.5 [alg.replace]/1.
27617 </p>
27618 <blockquote><pre>template&lt;ForwardIterator Iter, class T&gt; 
27619   requires OutputIterator&lt;Iter, Iter::reference&gt; 
27620         &amp;&amp; OutputIterator&lt;Iter, const T&amp;&gt; 
27621         &amp;&amp; HasEqualTo&lt;Iter::value_type, T&gt; 
27622   void replace(Iter first, Iter last, 
27623                const T&amp; old_value, const T&amp; new_value); 
27624
27625 template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred, class T&gt; 
27626   requires OutputIterator&lt;Iter, Iter::reference&gt; 
27627         &amp;&amp; OutputIterator&lt;Iter, const T&amp;&gt; 
27628         &amp;&amp; CopyConstructible&lt;Pred&gt; 
27629   void replace_if(Iter first, Iter last, 
27630                   Pred pred, const T&amp; new_value);
27631 </pre>
27632 <blockquote>
27633 <del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del>
27634 </blockquote>
27635 </blockquote>
27636 </li>
27637 <li>
27638 <p>
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.".
27642 </p>
27643 <blockquote><pre>template&lt;InputIterator InIter, typename OutIter, class T&gt; 
27644   requires OutputIterator&lt;OutIter, InIter::reference&gt; 
27645         &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt; 
27646         &amp;&amp; HasEqualTo&lt;InIter::value_type, T&gt; 
27647   OutIter replace_copy(InIter first, InIter last, 
27648                        OutIter result, 
27649                        const T&amp; old_value, const T&amp; new_value);
27650
27651 template&lt;InputIterator InIter, typename OutIter,
27652          Predicate&lt;auto, InIter::value_type&gt; Pred, class T&gt; 
27653   requires OutputIterator&lt;OutIter, InIter::reference&gt; 
27654         &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt; 
27655         &amp;&amp; CopyConstructible&lt;Pred&gt; 
27656   OutIter replace_copy_if(InIter first, InIter last, 
27657                           OutIter result, 
27658                           Pred pred, const T&amp; new_value);
27659 </pre>
27660 <blockquote>
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.
27665 </blockquote>
27666 </blockquote>
27667 </li>
27668 </ol>
27669
27670
27671
27672
27673
27674 <hr>
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>
27681 <p>
27682 25.3.9 [alg.unique]/2: "Requires: The comparison function shall be an
27683 equivalence relation."
27684 </p>
27685
27686 <p>
27687 The essence of this is already covered by the given requirement
27688 </p>
27689
27690 <blockquote><pre>EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred
27691 </pre></blockquote>
27692
27693 <p>
27694 and should thus be removed.
27695 </p>
27696
27697 <p><i>[
27698 Batavia (2009-05):
27699 ]</i></p>
27700
27701 <blockquote>
27702 We agree with the proposed resolution.
27703 Move to Tentatively Ready.
27704 </blockquote>
27705
27706
27707 <p><b>Proposed resolution:</b></p>
27708 <p>
27709 Remove 25.3.9 [alg.unique]/2
27710 </p>
27711
27712 <blockquote><pre>template&lt;ForwardIterator Iter&gt;
27713   requires OutputIterator&lt;Iter, Iter::reference&gt;
27714         &amp;&amp; EqualityComparable&lt;Iter::value_type&gt;
27715   Iter unique(Iter first, Iter last);
27716
27717 template&lt;ForwardIterator Iter, EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred&gt;
27718   requires OutputIterator&lt;Iter, RvalueOf&lt;Iter::reference&gt;::type&gt;
27719         &amp;&amp; CopyConstructible&lt;Pred&gt;
27720   Iter unique(Iter first, Iter last,
27721                Pred pred);
27722 </pre>
27723 <blockquote>
27724 <p>
27725 1 <i>Effects:</i> ...
27726 </p>
27727 <p>
27728 <del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del>
27729 </p>
27730 </blockquote>
27731 </blockquote>
27732
27733
27734
27735
27736
27737 <hr>
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&amp;</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>
27745 <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
27749 this point:
27750 </p>
27751
27752 <blockquote>
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&lt;const T&amp;, const T&amp;&gt;</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&amp;</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.
27760 </blockquote>
27761
27762 <p><i>[
27763 Batavia (2009-05):
27764 ]</i></p>
27765
27766 <blockquote>
27767 We agree with the proposed resolution.
27768 Move to Tentatively Ready.
27769 </blockquote>
27770
27771 <p><i>[
27772 2009-07 Frankfurt
27773 ]</i></p>
27774
27775
27776 <blockquote>
27777 Moved from Tentatively Ready to Open only because the wording needs to be
27778 tweaked for concepts removal.
27779 </blockquote>
27780
27781 <p><i>[
27782 2009-08-18 Daniel adds:
27783 ]</i></p>
27784
27785
27786 <blockquote>
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>.
27790 </blockquote>
27791
27792 <p><i>[
27793 2009-10 Santa Cruz:
27794 ]</i></p>
27795
27796
27797 <blockquote>
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
27801 attention.
27802 </blockquote>
27803
27804 <p><i>[
27805 2010 Pittsburgh:  Pete to reapply
27806 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>.
27807 ]</i></p>
27808
27809
27810
27811
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>.
27815
27816
27817 <p><b>Proposed resolution:</b></p>
27818 <ol>
27819 <li>
27820 <p>
27821 In 25 [algorithms]/2, header <tt>&lt;algorithm&gt;</tt> synopsis change as indicated:
27822 </p>
27823
27824 <blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
27825 <ins>requires CopyConstructible&lt;T&gt;</ins>
27826 pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
27827 minmax(initializer_list&lt;T&gt; t);
27828
27829 template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
27830 <ins>requires CopyConstructible&lt;T&gt;</ins>
27831 pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
27832 minmax(initializer_list&lt;T&gt; t, Compare comp);
27833 </pre></blockquote>
27834 </li>
27835 <li>
27836 <p>
27837 In 25.4.7 [alg.min.max] change as indicated (Begin: Just before p.20):
27838 </p>
27839 <blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
27840   <ins>requires CopyConstructible&lt;T&gt;</ins>
27841   pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
27842   minmax(initializer_list&lt;T&gt; t);
27843 </pre>
27844 <blockquote>
27845 <p>
27846 <del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
27847 <tt>CopyConstructible</tt>.</del>
27848 </p>
27849 <p>
27850 -21- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
27851 </del>T<del>&amp;</del>&gt;(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>.
27853 </p>
27854 </blockquote>
27855
27856 <p>[..]</p>
27857 <pre>template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
27858   <ins>requires CopyConstructible&lt;T&gt;</ins>
27859   pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
27860   minmax(initializer_list&lt;T&gt; t, Compare comp);
27861 </pre>
27862
27863 <blockquote>
27864 <p>
27865 <del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
27866 </p>
27867 <p>
27868 -25- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
27869 </del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
27870 smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
27871 </p>
27872 </blockquote>
27873 </blockquote>
27874 </li>
27875 </ol>
27876
27877
27878
27879
27880
27881
27882 <hr>
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>
27890
27891 <p>
27892 The current WP provides the following assignment operators for <tt>pair</tt>
27893 in 20.3.5 [pairs]/1:
27894 </p>
27895
27896 <ol>
27897 <li>
27898 <pre>template&lt;class U , class V&gt;
27899 requires HasAssign&lt;T1, const U&amp;&gt; &amp;&amp; HasAssign&lt;T2, const V&amp;&gt;
27900 pair&amp; operator=(const pair&lt;U , V&gt;&amp; p);
27901 </pre>
27902 </li>
27903 <li>
27904 <pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
27905 </pre>
27906 </li>
27907 <li>
27908 <pre>template&lt;class U , class V&gt;
27909 requires HasAssign&lt;T1, RvalueOf&lt;U&gt;::type&gt; &amp;&amp; HasAssign&lt;T2, RvalueOf&lt;V&gt;::type&gt;
27910 pair&amp; operator=(pair&lt;U , V&gt;&amp;&amp; p);
27911 </pre>
27912 </li>
27913 </ol>
27914
27915 <p>
27916 It seems that the functionality of (2) is completely covered by (3), therefore
27917 (2) should be removed.
27918 </p>
27919
27920 <p><i>[
27921 Batavia (2009-05):
27922 ]</i></p>
27923
27924 <blockquote>
27925 <p>
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.
27928 </p>
27929 <p>
27930 Move to Open.
27931 We recommend this be looked at in the context of the ongoing work
27932 related to the pair templates.
27933 </p>
27934 </blockquote>
27935
27936 <p><i>[
27937 2009-07 Frankfurt:
27938 ]</i></p>
27939
27940
27941 <blockquote>
27942 Leave this open pending the removal of concepts from the WD.
27943 </blockquote>
27944
27945 <p><i>[
27946 2009-10 Santa Cruz:
27947 ]</i></p>
27948
27949
27950 <blockquote>
27951 Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
27952 </blockquote>
27953
27954
27955
27956 <p><b>Proposed resolution:</b></p>
27957 <ol type="A">
27958 <li>
27959 <p>
27960 In 20.3.5 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
27961 </p>
27962
27963 <blockquote><pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
27964 </pre></blockquote>
27965 </li>
27966
27967 <li>
27968 Remove p.13+p.14
27969 </li>
27970
27971 </ol>
27972
27973
27974
27975
27976
27977 <hr>
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>
27985 <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
27990 editorial process?
27991 </p>
27992
27993 <p><i>[
27994 Post Summit Daniel provided wording.
27995 ]</i></p>
27996
27997
27998 <p><i>[
27999 Batavia (2009-05):
28000 ]</i></p>
28001
28002 <blockquote>
28003 <p>
28004 We believe that the proposed resolution's part 1 is editorial.
28005 </p>
28006 <p>
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.
28011 </p>
28012 <p>
28013 We recommend that the Project Editor restore the missing declaration
28014 and that we keep part 2 of the issue alive.
28015 </p>
28016 <p>
28017 Move to Open.
28018 </p>
28019 </blockquote>
28020
28021 <p><i>[
28022 2009-07 Frankfurt:
28023 ]</i></p>
28024
28025
28026 <blockquote>
28027 Leave this open pending the removal of concepts from the WD.
28028 </blockquote>
28029
28030 <p><i>[
28031 2009-10 Santa Cruz:
28032 ]</i></p>
28033
28034
28035 <blockquote>
28036 Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
28037 </blockquote>
28038
28039
28040
28041 <p><b>Proposed resolution:</b></p>
28042 <ol>
28043 <li>
28044 <p>
28045 In 20.4.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
28046 change as indicated:
28047 </p>
28048 <p><i>[
28049 This fixes an editorial loss between N2798 to N2800
28050 ]</i></p>
28051
28052 <blockquote><pre>template &lt;class... UTypes&gt;
28053 requires HasAssign&lt;Types, const UTypes&amp;&gt;...
28054 <ins>tuple&amp; operator=(const pair&lt;UTypes...&gt;&amp;);</ins>
28055
28056 template &lt;class... UTypes&gt;
28057 requires HasAssign&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
28058 <ins>tuple&amp; operator=(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
28059 </pre></blockquote>
28060 </li>
28061 <li>
28062 <p>
28063 In 20.4.2.1 [tuple.cnstr], starting just before p. 11 please remove
28064 as indicated:
28065 </p>
28066
28067 <blockquote><pre><del>requires MoveAssignable&lt;Types&gt;... tuple&amp; operator=(tuple&amp;&amp; u);</del>
28068 </pre>
28069 <blockquote>
28070 <p>
28071 <del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
28072 element of <tt>*this</tt>.</del>
28073 </p>
28074 <p>
28075 <del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
28076 </p>
28077 </blockquote>
28078 </blockquote>
28079 </li>
28080 </ol>
28081
28082
28083
28084
28085
28086 <hr>
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>
28092 <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.
28095 </p>
28096
28097 <p><i>[
28098 Post Summit Daniel adds
28099 ]</i></p>
28100
28101
28102 <blockquote>
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.
28106 </blockquote>
28107
28108 <p><i>[
28109 2009-05-01 Daniel adds:
28110 ]</i></p>
28111
28112
28113 <blockquote>
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
28118 NAD.
28119 </blockquote>
28120
28121 <p><i>[
28122 Batavia (2009-05):
28123 ]</i></p>
28124
28125 <blockquote>
28126 <p>
28127 We observed that all the proposed changes have already been applied to the
28128 Working Draft, rendering this issue moot.
28129 </p>
28130 <p>
28131 Move to NAD.
28132 </p>
28133 </blockquote>
28134
28135
28136
28137 <p><b>Proposed resolution:</b></p>
28138 <ol>
28139 <li>
28140 <p>
28141 In both 20.4.1 [tuple.general]/2 and 20.4.2.9 [tuple.special] change
28142 </p>
28143
28144 <blockquote><pre>template &lt;<del>class</del> <ins>Swappable</ins>... Types&gt;
28145 void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
28146 </pre></blockquote>
28147
28148 </li>
28149
28150 <li>
28151 <p>
28152 In 20.4.2 [tuple.tuple], class <tt>tuple</tt> definition and in
28153 20.4.2.3 [tuple.swap], change
28154 </p>
28155
28156 <blockquote><pre><ins>requires Swappable&lt;Types&gt;...</ins>void swap(tuple&amp;);
28157 </pre></blockquote>
28158
28159 </li>
28160
28161 <li>
28162 <p>
28163 In 20.4.2.3 [tuple.swap] remove the current requires-clause, which says:
28164 </p>
28165
28166 <blockquote>
28167 <del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del>
28168 </blockquote>
28169 </li>
28170
28171 </ol>
28172
28173
28174
28175
28176
28177
28178 <hr>
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>
28185 <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:
28188 </p>
28189
28190 <blockquote><pre>requires EqualityComparable&lt;T&gt; void remove(const T&amp; value);
28191 </pre></blockquote>
28192
28193 <p>
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
28197 pre-concept WP
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.
28201 </p>
28202
28203 <p><i>[
28204 Batavia (2009-05):
28205 ]</i></p>
28206
28207 <blockquote>
28208 <p>
28209 We agree with the proposed resolution,
28210 but would like additional input from concepts experts.
28211 </p>
28212 <p>
28213 Move to Review.
28214 </p>
28215 </blockquote>
28216
28217 <p><i>[
28218 2009-07-21 Alisdair adds:
28219 ]</i></p>
28220
28221
28222 <blockquote>
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.
28227 </blockquote>
28228
28229 <p><i>[
28230 2009-10-10 Daniel adds:
28231 ]</i></p>
28232
28233
28234 <blockquote>
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>
28237 has no longer the
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.
28243 </blockquote>
28244
28245 <p><i>[
28246 2009-10 Santa Cruz:
28247 ]</i></p>
28248
28249
28250 <blockquote>
28251 NAD, solved by the removal of concepts.
28252 </blockquote>
28253
28254
28255
28256 <p><b>Proposed resolution:</b></p>
28257 <ol type="A">
28258 <li>
28259 <p>
28260 Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
28261 </p>
28262
28263 <blockquote><pre>requires <del>EqualityComparable&lt;T&gt;</del> <ins>HasEqualTo&lt;T, T&gt;</ins> void remove(const T&amp; value);
28264 </pre></blockquote>
28265 </li>
28266 </ol>
28267
28268
28269
28270
28271
28272
28273 <hr>
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>
28281 <p>
28282 Right now, C++0x doesn't have <tt>atomic&lt;float&gt;</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.
28285 </p>
28286 <p>
28287 <b>Proposed resolutions:</b> Using <tt>atomic&lt;FP&gt;::compare_exchange</tt> (weak or
28288 strong) should be either:
28289 </p>
28290
28291 <ol>
28292 <li>
28293 ill-formed, or
28294 </li>
28295 <li>
28296 well-defined.
28297 </li>
28298 </ol>
28299
28300 <p>
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).
28304 </p>
28305
28306 <p><i>[
28307 Summit:
28308 ]</i></p>
28309
28310
28311 <blockquote>
28312 Move to open. Blocked until concepts for atomics are addressed.
28313 </blockquote>
28314
28315 <p><i>[
28316 Post Summit Anthony adds:
28317 ]</i></p>
28318
28319
28320 <blockquote>
28321 <p>
28322 Recommend NAD. C++0x does have <tt>std::atomic&lt;float&gt;</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:
28325 </p>
28326
28327 <blockquote>
28328 <p>
28329 [<i>Note:</i> The effect of the compare-and-exchange operations is
28330 </p>
28331 <blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
28332     *object = desired;
28333 else
28334     *expected = *object;
28335 </pre></blockquote>
28336
28337 <p>
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>]
28341 </p>
28342 </blockquote>
28343
28344 </blockquote>
28345
28346 <p><i>[
28347 2009-10 Santa Cruz:
28348 ]</i></p>
28349
28350
28351 <blockquote>
28352 NAD Editorial.  Solved by
28353 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28354 </blockquote>
28355
28356
28357
28358 <p><b>Proposed resolution:</b></p>
28359 <p>
28360 Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
28361 </p>
28362
28363 <blockquote>
28364 <p>
28365 [<i>Note:</i> The effect of the compare-and-exchange operations is
28366 </p>
28367 <blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
28368     *object = desired;
28369 else
28370     *expected = *object;
28371 </pre></blockquote>
28372
28373 <p><ins>
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>]
28377 </p>
28378 </blockquote>
28379
28380
28381
28382
28383
28384
28385 <hr>
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>
28393 <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.
28397 </p>
28398 <p>
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
28405 no padding.
28406 </p>
28407 <p>
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>.
28412 </p>
28413
28414 <p>
28415 <b>Proposed resolutions:</b> Using
28416 <tt>atomic&lt;struct-with-padding&gt;::compare_exchange_strong</tt> should be either:
28417 </p>
28418
28419 <ol>
28420 <li>
28421 ill-formed, or
28422 </li>
28423 <li>
28424 well-defined.
28425 </li>
28426 </ol>
28427
28428 <p>
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
28434 support.)
28435 </p>
28436
28437 <p><i>[
28438 Summit:
28439 ]</i></p>
28440
28441
28442 <blockquote>
28443 Move to open. Blocked until concepts for atomics are addressed.
28444 </blockquote>
28445
28446 <p><i>[
28447 Post Summit Anthony adds:
28448 ]</i></p>
28449
28450
28451 <blockquote>
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.
28453 </blockquote>
28454
28455 <p><i>[
28456 2009-10 Santa Cruz:
28457 ]</i></p>
28458
28459
28460 <blockquote>
28461 NAD Editorial.  Solved by
28462 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28463 </blockquote>
28464
28465
28466
28467 <p><b>Proposed resolution:</b></p>
28468 <p>
28469 </p>
28470
28471
28472
28473
28474
28475 <hr>
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>
28483
28484 <p>
28485 There was an interesting issue raised over on comp.programming.threads
28486 today regarding the following example
28487 </p>
28488
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
28495
28496 // Thread 2:
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>
28501
28502 <p>
28503 is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
28504 </p>
28505 <p>
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:
28508 </p>
28509 <p>
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>.
28514 </p>
28515 <p>
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>:
28518 </p>
28519
28520 <blockquote>
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
28528 order.
28529 </blockquote>
28530
28531 <p>
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.
28535 </p>
28536 <p>
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>.
28539 </p>
28540 <p>
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>
28543 must see 1.
28544 </p>
28545 <p>
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>.
28549 </p>
28550 <p>
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.
28556 </p>
28557 <p>
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.
28561 </p>
28562 <p>
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
28565 <tt>SY2</tt>.
28566 </p>
28567 <p>
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.
28574 </p>
28575
28576 <p><i>[
28577 Post Summit Hans adds:
28578 ]</i></p>
28579
28580
28581 <blockquote>
28582 <p>
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
28590 disaster either.
28591 </p>
28592 <p>
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]:
28595 </p>
28596 <blockquote>
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.]
28604 </blockquote>
28605
28606 <p>
28607 Also see thread beginning at c++std-lib-23271.
28608 </p>
28609
28610 </blockquote>
28611
28612 <p><i>[
28613 Herve's correction:
28614 ]</i></p>
28615
28616 <blockquote>
28617 <p>
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
28621 think you meant:
28622 </p>
28623
28624 <blockquote>
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 . . .
28628 </blockquote>
28629 <p>
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.
28633 </p>
28634 </blockquote>
28635
28636 <p><i>[
28637 2009-10 Santa Cruz:
28638 ]</i></p>
28639
28640
28641 <blockquote>
28642 NAD Editorial.  Solved by
28643 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28644 </blockquote>
28645
28646
28647
28648 <p><b>Proposed resolution:</b></p>
28649 <p>
28650 Add a new paragraph after 29.3 [atomics.order]p5 that says
28651 </p>
28652
28653 <blockquote>
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
28660 <tt>M</tt>.
28661 </blockquote>
28662
28663
28664
28665
28666
28667 <hr>
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>
28673 <p>
28674 X [allocator.concepts] contains a reference to a concept named
28675 <tt>Dereferenceable</tt>. No such concept exists.
28676 </p>
28677
28678 <p><i>[
28679 Daniel adds 2009-02-14:
28680 ]</i></p>
28681
28682
28683 <blockquote>
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.
28687 </blockquote>
28688
28689
28690 <p><i>[
28691 Batavia (2009-05):
28692 ]</i></p>
28693
28694 <blockquote>
28695 <p>
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.
28699 </p>
28700 <p>
28701 Move to NAD Editorial.
28702 </p>
28703 </blockquote>
28704
28705
28706 <p><b>Proposed resolution:</b></p>
28707 <p>
28708 Change all uses of the concept <tt>Dereferenceable</tt> to
28709 <tt>HasDereference</tt> in X [allocator.concepts].
28710 </p>
28711
28712
28713
28714
28715
28716 <hr>
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>
28723 <p>
28724 In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator&lt;</tt>
28725 are declared as 
28726 </p>
28727
28728 <blockquote><pre>template&lt;class... TTypes, class... UTypes&gt; 
28729   requires EqualityComparable&lt;TTypes, UTypes&gt;... 
28730   bool operator==(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
28731 </pre></blockquote>
28732
28733 <p>
28734 and
28735 </p>
28736
28737 <blockquote><pre>template&lt;class... TTypes, class... UTypes&gt; 
28738   requires LessThanComparable&lt;TTypes, UTypes&gt;... 
28739   bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
28740 </pre></blockquote>
28741
28742 <p>
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&lt;()</tt> should also require 
28746 </p>
28747
28748 <blockquote><pre>LessThanComparable&lt;UTypes, TTypes&gt;... // (note the order) 
28749 </pre></blockquote>
28750
28751 <p>
28752 since the algorithm for <tt>tuple::operator&lt;</tt> is the following (pseudo-code)
28753 </p>
28754
28755 <blockquote><pre>for (size_t N = 0; N &lt; sizeof...(TTypes); ++N) { 
28756     if (get&lt;N&gt;(t) &lt; get&lt;N&gt;(u) return true; 
28757     else if ((get&lt;N&gt;(u) &lt; get&lt;N&gt;(t)) return false; 
28758
28759
28760 return false; 
28761 </pre></blockquote>
28762
28763 <p>
28764 Similar problems hold for <tt>tuples</tt>'s other comparison operators.
28765 </p>
28766
28767 <p><i>[
28768 Post Summit:
28769 ]</i></p>
28770
28771
28772 <blockquote>
28773 Recommend Tentatively Ready.
28774 </blockquote>
28775
28776
28777
28778 <p><b>Proposed resolution:</b></p>
28779 <p>
28780 In 20.4.1 [tuple.general] and 20.4.2.7 [tuple.rel] change:
28781 </p>
28782
28783 <blockquote><pre>template&lt;class... TTypes, class... UTypes&gt;
28784   requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;TTypes, UTypes&gt;...
28785   bool operator==(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28786
28787 template&lt;class... TTypes, class... UTypes&gt;
28788   requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;TTypes, UTypes&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
28789   bool operator&lt;(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28790
28791 template&lt;class... TTypes, class... UTypes&gt;
28792   requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;TTypes, UTypes&gt;...
28793   bool operator!=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28794
28795 template&lt;class... TTypes, class... UTypes&gt;
28796   requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
28797   bool operator&gt;(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28798
28799 template&lt;class... TTypes, class... UTypes&gt;
28800   requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
28801   bool operator&lt;=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28802
28803 template&lt;class... TTypes, class... UTypes&gt;
28804   requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;TTypes, UTypes&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
28805   bool operator&gt;=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
28806 </pre></blockquote>
28807
28808
28809
28810
28811
28812 <hr>
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>
28819
28820 <p>
28821 The Working Draft (N2798) allows access to the elements of
28822 <tt>std::array</tt> by its <tt>data()</tt> member function:
28823 </p>
28824
28825 <blockquote>
28826
28827 <h5>23.2.1.4 array::data [array.data]</h5>
28828 <pre> T *data();
28829  const T *data() const;
28830 </pre>
28831 <ol><li>
28832  Returns: elems.
28833 </li></ol>
28834 </blockquote>
28835
28836 <p>
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:
28843 </p>
28844
28845 <pre> // Some C style API function. 
28846  void set_path( char (*)[MAX_PATH] );
28847
28848  std::array&lt;char,MAX_PATH&gt; path;
28849  set_path( path.data() );  // error
28850  set_path( &amp;(path.data()) );  // error
28851 </pre>
28852
28853  <p>
28854 Another example, trying to pass the array data to an instance of another
28855 C++ class:
28856 </p>
28857
28858 <pre> // Represents a 3-D point in space.
28859  class three_d_point {
28860  public:
28861    explicit three_d_point(const double (&amp;)[3]); 
28862  };
28863
28864  const std::array&lt;double,3&gt; coordinates = { 0, 1, 2 };
28865  three_d_point point1( coordinates.data() );  // error.
28866  three_d_point point2( *(coordinates.data()) );  // error.
28867 </pre>
28868
28869 <p>
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
28876 </p>
28877 <p>
28878 I can think of three options to solve this issue:
28879 </p>
28880 <ol><li>
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."
28884 </li><li>
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
28887 first element.
28888 </li><li>
28889 Add extra member functions, returning a reference to the built-in array.
28890 </li></ol>
28891 <p>
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
28896 stack sizes.
28897 </p>
28898 <p>
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.
28908 </p>
28909
28910 <pre> template &lt;typename T&gt;
28911  void func(T&amp; container1, T&amp; container2)
28912  {
28913    // Are data1 and data2 pointers or references?
28914    auto data1 = container1.data();
28915    auto data2 = container2.data();
28916
28917    // Will this swap two local pointers, or all container elements?
28918    std::swap(data1, data2);
28919  }
28920 </pre>
28921
28922 <p>
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):
28927 </p>
28928
28929 <pre> auto concept ContiguousContainerConcept&lt;typename T&gt;
28930  {
28931    typename value_type = typename T::value_type;
28932    const value_type * T::data() const;
28933  }
28934 </pre>
28935
28936 <p>
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.
28941 </p>
28942 <p>
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.
28949 </p>
28950 <p>
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.
28963 </p>
28964
28965 <p><i>[
28966 Post Summit:
28967 ]</i></p>
28968
28969
28970 <blockquote>
28971
28972 <p>
28973 Alisdair: Don't like p4 suggesting implementation-defined behaviour.
28974 </p>
28975 <p>
28976 Walter: What about an explicit conversion operator, instead of adding
28977 the new member function?
28978 </p>
28979 <p>
28980 Alisdair: Noodling about:
28981 </p>
28982 <blockquote><pre>template&lt;size_t N, ValueType T&gt;
28983 struct array
28984 {
28985   T elems[N];
28986
28987 // fantasy code starts here
28988
28989 // crazy decltype version for grins only
28990 //requires True&lt;(N&gt;0)&gt;
28991 //explict operator decltype(elems) &amp; () { return elems; }
28992
28993 // conversion to lvalue ref
28994 requires True&lt;(N&gt;0)&gt;
28995 explict operator T(&amp;)[N] () &amp; { return elems; }
28996
28997 // conversion to const lvalue ref
28998 requires True&lt;(N&gt;0)&gt;
28999 explict operator const T(&amp;)[N] () const &amp; { return elems; }
29000
29001 // conversion to rvalue ref using ref qualifiers
29002 requires True&lt;(N&gt;0)&gt;
29003 explict operator T(&amp;&amp;)[N] () &amp;&amp; { return elems; }
29004
29005 // fantasy code ends here
29006
29007 explicit operator bool() { return true; }
29008 };
29009 </pre></blockquote>
29010
29011 <p>
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.
29016 </p>
29017 <p>
29018 Some grumbling about zero-sized arrays being allowed and supported.
29019 </p>
29020 <p>
29021 Walter: Would this address the issue? Are we inclined to go this route?
29022 </p>
29023 <p>
29024 Alan: What would usage look like?
29025 </p>
29026 <blockquote><pre>// 3-d point in space
29027 struct three_d_point
29028 {
29029   explicit three_d_point(const double (&amp;)[3]);
29030 };
29031
29032 void sink(double*);
29033
29034 const std::array&lt;double, 3&gt; 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!
29038
29039 sink(cooridinates); // error, no conversion
29040 </pre></blockquote>
29041
29042 <p>
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.
29047 </p>
29048
29049 </blockquote>
29050
29051 <p><i>[
29052 Post Summit, further discussion in the thread starting with c++std-lib-23215.
29053 ]</i></p>
29054
29055
29056 <p><i>[
29057 2009-07 post-Frankfurt (Saturday afternoon group):
29058 ]</i></p>
29059
29060
29061 <blockquote>
29062 <p>
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).
29072 </p>
29073 <p>
29074 Move to Review
29075 </p>
29076 </blockquote>
29077
29078 <p><i>[
29079 2009-07-31 Alisdair adds:
29080 ]</i></p>
29081
29082
29083 <blockquote>
29084 <p>
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 &amp;&amp;</tt> (if any.)
29089 </p>
29090
29091 <p>
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.
29095 </p>
29096
29097 <p>
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.
29101 </p>
29102 </blockquote>
29103
29104 <p><i>[
29105 2009-10 Santa Cruz:
29106 ]</i></p>
29107
29108
29109 <blockquote>
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.
29113 </blockquote>
29114
29115
29116
29117 <p><b>Proposed resolution:</b></p>
29118 <p>
29119 Add to the template definition of array, 23.3.1 [array]/3:
29120 </p>
29121
29122 <blockquote>
29123 <pre><ins>
29124 typedef T c_array_type[N];
29125 c_array_type &amp; c_array() &amp;;
29126 c_array_type &amp;&amp; c_array() &amp;&amp;;
29127 const c_array_type &amp; c_array() const &amp;;
29128 </ins>
29129 </pre>
29130 </blockquote>
29131
29132 <p>
29133 Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
29134 </p>
29135
29136 <blockquote>
29137 <h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
29138     <pre><ins>
29139 c_array_type &amp; c_array() &amp;;
29140 c_array_type &amp;&amp; c_array() &amp;&amp;;
29141 const c_array_type &amp; c_array() const &amp;;
29142 </ins></pre>
29143 <blockquote>
29144 <p>
29145 <ins><i>Returns:</i> <tt>elems</tt>.</ins>
29146 </p>
29147 </blockquote>
29148
29149 </blockquote>
29150
29151
29152
29153 <p>
29154 Change Zero sized arrays 23.3.1.7 [array.zero]:
29155 </p>
29156
29157 <blockquote>
29158
29159 <p>-2- ...</p>
29160
29161 <p><ins>
29162 The type <tt>c_array_type</tt> is unspecified for a zero-sized array.
29163 </ins></p>
29164
29165 <p>
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.
29168 </p>
29169 </blockquote>
29170
29171
29172
29173
29174
29175
29176 <hr>
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>
29183 <p>
29184 If we are supporting stateful deleters, we need an overload for
29185 <tt>reset</tt> that
29186 takes a deleter as well.
29187 </p>
29188
29189 <blockquote><pre>void reset( pointer p, deleter_type d);
29190 </pre></blockquote>
29191
29192 <p>
29193 We probably need two overloads to support move-only deleters, and
29194 this
29195 sounds uncomfortably like the two constructors I have been ignoring
29196 for
29197 now...
29198 </p>
29199
29200 <p><i>[
29201 Batavia (2009-05):
29202 ]</i></p>
29203
29204 <blockquote>
29205 <p>
29206 Howard comments that we have the functionality via move-assigment.
29207 </p>
29208 <p>
29209 Move to Open.
29210 </p>
29211 </blockquote>
29212
29213 <p><i>[
29214 2009-10 Santa Cruz:
29215 ]</i></p>
29216
29217
29218 <blockquote>
29219 Mark as NAD Future.
29220 </blockquote>
29221
29222
29223
29224 <p><b>Proposed resolution:</b></p>
29225 <p>
29226 </p>
29227
29228
29229
29230
29231
29232 <hr>
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>
29238 <p>
29239 Each of the three clocks specified in Clocks 20.11.5 [time.clock]
29240 provides the member function:
29241 </p>
29242
29243 <blockquote><pre>static time_point now();
29244 </pre></blockquote>
29245
29246 <p>
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]
29250 paragraph 4).
29251 </p>
29252
29253 <p>
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>
29258 function.
29259 </p>
29260
29261 <p>
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.
29269 </p>
29270
29271 <p>
29272 The proposed resolution has been implemented in the Boost version of the
29273 chrono library. No problems were encountered.
29274 </p>
29275
29276 <p><i>[
29277 Batavia (2009-05):
29278 ]</i></p>
29279
29280 <blockquote>
29281 <p>
29282 We recommend this issue be deferred until the next Committee Draft
29283 has been issued and the prerequisite paper has been accepted.
29284 </p>
29285 <p>
29286 Move to Open.
29287 </p>
29288 </blockquote>
29289
29290 <p><i>[
29291 2009-10 Santa Cruz:
29292 ]</i></p>
29293
29294
29295 <blockquote>
29296 Mark as NAD future. Too late to make this change without having already
29297 accepted the hybrid error handling proposal.
29298 </blockquote>
29299
29300
29301
29302 <p><b>Proposed resolution:</b></p>
29303 <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>.
29307 </p>
29308
29309 <p>
29310 Change Clock requirements 20.11.1 [time.clock.req] as indicated:
29311 </p>
29312
29313 <blockquote>
29314 <p>
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>
29321 </p>
29322
29323 <table border="1">
29324 <caption>Table 55 -- Clock requirements</caption>
29325 <tbody><tr>
29326 <th>Expression</th><th>Return type</th><th>Operational semantics</th>
29327 </tr>
29328
29329 <tr>
29330 <td>...</td>
29331 <td>...</td>
29332 <td>...</td>
29333 </tr>
29334
29335 <tr>
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.
29339 </td>
29340 </tr>
29341
29342 <tr>
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>
29346 </td>
29347 </tr>
29348 </tbody></table>
29349 </blockquote>
29350
29351 <p>
29352 Change Class system_clock 20.11.5.1 [time.clock.system] as indicated:
29353 </p>
29354
29355 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
29356 </pre></blockquote>
29357
29358 <p>
29359 Change Class monotonic_clock X [time.clock.monotonic] as indicated:
29360 </p>
29361
29362 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
29363 </pre></blockquote>
29364
29365 <p>
29366 Change Class high_resolution_clock 20.11.5.3 [time.clock.hires] as indicated:
29367 </p>
29368
29369 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
29370 </pre></blockquote>
29371
29372
29373
29374
29375
29376
29377 <hr>
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>
29385
29386
29387
29388 <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>.
29395 </p>
29396
29397 <p>
29398 The requirements for a Mutex type include:
29399 </p>
29400
29401 <ul>
29402 <li>
29403 <tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
29404 </li>
29405 <li>
29406 <tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
29407 </li>
29408 <li>
29409 <tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
29410 </li>
29411 </ul>
29412
29413 <p>
29414 Also, a Mutex type "shall not be copyable nor movable".
29415 </p>
29416
29417 <p>
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>.
29427 </p>
29428
29429 <p><i>[
29430 Summit:
29431 ]</i></p>
29432
29433
29434 <blockquote>
29435 <p>
29436 Move to open. Related to conceptualization and should probably be tackled as part of that.
29437 </p>
29438 <ul>
29439 <li>
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
29444 standard.
29445 </li>
29446 <li>
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.
29449 </li>
29450 </ul>
29451 </blockquote>
29452
29453 <p><i>[
29454 Post Summit Anthony adds:
29455 ]</i></p>
29456
29457
29458 <blockquote>
29459 <p>
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.
29464 </p>
29465 <p>
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.
29474 </p>
29475 </blockquote>
29476
29477
29478
29479 <p><b>Proposed resolution:</b></p>
29480 <p>
29481 </p>
29482
29483
29484
29485
29486
29487 <hr>
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>
29495
29496 <p><b>Addresses US 89</b></p>
29497
29498 <blockquote>
29499 <p>
29500 The types in the table "Atomics for standard typedef types" should be
29501 typedefs, not classes. These semantics are necessary for compatibility
29502 with C.
29503 </p>
29504
29505 <p>
29506 Change the classes to typedefs.
29507 </p>
29508 </blockquote>
29509
29510 <p>
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>&lt;cstdint&gt;</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>&lt;cstdint&gt;</tt>
29519 typedef is required to be a distinct class.
29520 </p>
29521
29522 <p>
29523 It shouldn't be required that the atomic analog of every <tt>&lt;cstdint&gt;</tt>
29524 typedef be a typedef for some fundamental integer type. After all,
29525 <tt>&lt;cstdint&gt;</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.
29531 </p>
29532
29533 <p>
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.
29536 </p>
29537
29538 <p><i>[
29539 Summit:
29540 ]</i></p>
29541
29542
29543 <blockquote>
29544 <p>
29545 Change status to NAD, editorial. See US 89 comment notes above.
29546 </p>
29547 <p>
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
29551 with C.
29552 </p>
29553 </blockquote>
29554
29555
29556 <p><b>Proposed resolution:</b></p>
29557 <p>
29558 </p>
29559
29560
29561
29562
29563
29564 <hr>
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>
29571
29572 <p><b>Addresses UK 270</b></p>
29573
29574 <p>
29575 Regarding the <tt>std::distance</tt> - function, 24.4.4 [iterator.operations]
29576 / 4 says:
29577 </p>
29578 <blockquote>
29579 Returns the
29580 number of increments or decrements needed to get from first to last.
29581 </blockquote>
29582 <p>
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.
29591 </p>
29592 <p>
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>).
29597 </p>
29598 <p>
29599 Here are my two questions:
29600 </p>
29601 <p>
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.
29606 </p>
29607 <p>
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 ?
29611 </p>
29612
29613 <p><i>[
29614 Daniel adds:
29615 ]</i></p>
29616
29617
29618 <blockquote>
29619 <p>
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:
29623 </p>
29624
29625 <p>
29626 Referring to
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:
29629 </p>
29630
29631 <blockquote>
29632 <i>Effects:</i> Returns the number of increments or decrements needed to get
29633 from <tt>first</tt> to <tt>last</tt>.
29634 </blockquote>
29635
29636 <p>
29637 IMO the part " or decrements" is in contradiction to p. 5 which says
29638 </p>
29639
29640 <blockquote>
29641 <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
29642 </blockquote>
29643
29644 <p>
29645 because "reachable" is defined in X [iterator.concepts]/7 as
29646 </p>
29647
29648 <blockquote>
29649 An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
29650 there is a finite
29651 sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
29652 </blockquote>
29653
29654 <p>
29655 Here is wording that would be consistent with this definition of "reachable":
29656 </p>
29657
29658 <p>
29659 Change 24.4.4 [iterator.operations] p4 as follows:
29660 </p>
29661
29662 <blockquote>
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>.
29665 </blockquote>
29666
29667 </blockquote>
29668
29669 <p>
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>.
29672 </p>
29673
29674 <p><i>[
29675 Summit:
29676 ]</i></p>
29677
29678
29679 <blockquote>
29680 The proposed wording below was verbally agreed to.  Howard provided.
29681 </blockquote>
29682
29683 <p><i>[
29684 Batavia (2009-05):
29685 ]</i></p>
29686
29687 <blockquote>
29688 <p>
29689 Pete reports that a recent similar change has been made
29690 for the <tt>advance()</tt> function.
29691 </p>
29692 <p>
29693 We agree with the proposed resolution.
29694 Move to Tentatively Ready.
29695 </p>
29696 </blockquote>
29697
29698 <p><i>[
29699 2009-07 Frankfurt
29700 ]</i></p>
29701
29702
29703 <blockquote>
29704 Moved from Tentatively Ready to Open only because the wording needs to be
29705 tweaked for concepts removal.
29706 </blockquote>
29707
29708 <p><i>[
29709 2009-07 Frankfurt:
29710 ]</i></p>
29711
29712
29713 <blockquote>
29714 Leave Open pending arrival of a post-Concepts WD.
29715 </blockquote>
29716
29717 <p><i>[
29718 2009-10-14 Daniel provided de-conceptified wording.
29719 ]</i></p>
29720
29721
29722 <p><i>[
29723 2009-10 Santa Cruz:
29724 ]</i></p>
29725
29726
29727 <blockquote>
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.".
29732 </blockquote>
29733
29734 <p><i>[
29735 2010 Pittsburgh:
29736 ]</i></p>
29737
29738
29739 <blockquote>
29740 Moved to NAD Editorial.  Rationale added below.
29741 </blockquote>
29742
29743
29744
29745 <p><b>Rationale:</b></p>
29746 <p>
29747 Solved by N3066.
29748 </p>
29749
29750
29751 <p><b>Proposed resolution:</b></p>
29752 <ol>
29753 <li>
29754 <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:
29759 </p>
29760
29761 <blockquote><pre><del>(a &lt; b) ? </del>distance(a,b)
29762 <del>: -distance(b,a)</del>
29763 </pre></blockquote>
29764 </li>
29765
29766 <li>
29767 <p>
29768 Change 24.4.4 [iterator.operations]/4+5 as indicated:
29769 </p>
29770
29771 <blockquote><pre>template&lt;class InputIterator&gt;
29772   typename iterator_traits&lt;InputIterator&gt;::difference_type
29773     distance(InputIterator first, InputIterator last);
29774 </pre>
29775 <blockquote>
29776 <p>
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
29781 <tt>last</tt>.
29782 </p>
29783
29784 <p>
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>.
29789 </p>
29790 </blockquote>
29791 </blockquote>
29792 </li>
29793 </ol>
29794
29795
29796
29797
29798
29799
29800
29801
29802
29803 <hr>
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>
29811 <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:
29816 </p>
29817 <blockquote><pre>if ( func() = value )  // Typical typo: == intended!
29818 </pre></blockquote>
29819 <p>
29820 Built-in types don't support assignment to an rvalue, but unfortunately,
29821 a lot of types provided by the Standard Library do.
29822 </p>
29823 <p>
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>&amp;</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
29831 </p>
29832 <p>
29833 Hereby I would like to propose adding ref-qualifiers to all appropriate
29834 assignment operators in the library.
29835 </p>
29836
29837 <p><i>[
29838 Batavia (2009-05):
29839 ]</i></p>
29840
29841 <blockquote>
29842 Move to Open.
29843 We recommend this be deferred until after the next Committee Draft.
29844 </blockquote>
29845
29846 <p><i>[
29847 Frankfurt 2009-07:
29848 ]</i></p>
29849
29850
29851 <blockquote>
29852 <p>
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>.
29855 </p>
29856 <p>
29857 Moved to NAD.
29858 </p>
29859 </blockquote>
29860
29861
29862 <p><b>Proposed resolution:</b></p>
29863 <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>
29867 </p>
29868
29869
29870
29871
29872
29873 <hr>
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>
29882
29883
29884
29885 <p>
29886 I'm looking at 29 [atomics] and can't really make sense of a couple of things.
29887 </p>
29888 <p>
29889 Firstly, there appears to be a typo in the <tt>&lt;cstdatomic&gt;</tt> synopsis:
29890 </p>
29891
29892 <blockquote>
29893 <p>
29894 The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt>
29895 is missing the second parameter:
29896 </p>
29897
29898 <blockquote><pre>void* atomic_exchange(volatile atomic_address*);
29899 </pre></blockquote>
29900
29901 <p>
29902 should be
29903 </p>
29904
29905 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
29906 </pre></blockquote>
29907
29908 <p>
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>.
29911 </p>
29912 </blockquote>
29913
29914
29915
29916 <p><b>Proposed resolution:</b></p>
29917 <p>
29918 Change the synopsis in 29 [atomics]/2:
29919 </p>
29920
29921 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
29922 </pre></blockquote>
29923
29924
29925
29926
29927
29928
29929 <hr>
29930 <h3><a name="944"></a>944. <tt>atomic&lt;bool&gt;</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>
29936 <p>
29937 I think it's fairly obvious that <tt>atomic&lt;bool&gt;</tt> is supposed to be derived
29938 from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic&lt;integral&gt;</tt> interface),
29939 though I think the current wording doesn't support this. I raised this
29940 point along with <tt>atomic&lt;floating-point&gt;</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
29943 problem.
29944 </p>
29945
29946 <p>
29947 29.5 [atomics.types.generic]/3 reads
29948 </p>
29949
29950 <blockquote>
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&lt;integral&gt;</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.
29957 </blockquote>
29958
29959 <p>
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.
29962 </p>
29963
29964 <p><i>[
29965 Summit:
29966 ]</i></p>
29967
29968
29969 <blockquote>
29970 Move to open. Lawrence will draft a proposed resolution. Also, ask
29971 Howard to fix the title.
29972 </blockquote>
29973
29974 <p><i>[
29975 Post Summit Anthony provided proposed wording.
29976 ]</i></p>
29977
29978
29979 <p><i>[
29980 2009-10 Santa Cruz:
29981 ]</i></p>
29982
29983
29984 <blockquote>
29985 NAD Editorial.  Solved by
29986 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
29987 </blockquote>
29988
29989
29990
29991 <p><b>Proposed resolution:</b></p>
29992 <p>
29993 Replace paragraph 3 in 29.5 [atomics.types.generic] with
29994 </p>
29995
29996 <blockquote>
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&lt;integral&gt;</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&lt;bool&gt;</tt>
30003 shall be publicly derived from <tt>atomic_bool</tt>.</ins>
30004 These specializations shall have trivial default
30005 constructors and trivial destructors.
30006 </blockquote>
30007
30008
30009
30010
30011
30012 <hr>
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>
30019 <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.
30022 </p>
30023
30024 <p><i>[
30025 Howard adds:
30026 ]</i></p>
30027
30028
30029 <blockquote>
30030 <p>
30031 This note refers to:
30032 </p>
30033
30034 <blockquote>
30035 -2- <tt>system_clock::duration::min() &lt; system_clock::duration::zero()</tt> shall be <tt>true</tt>.
30036 </blockquote>
30037
30038 <p>
30039 I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed".
30040 Perhaps an editorial note along the lines of:
30041 </p>
30042
30043 <blockquote>
30044 -2- <tt>system_clock::duration::min() &lt; 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>
30046 </blockquote>
30047
30048 <p>
30049 ?
30050 </p>
30051
30052 </blockquote>
30053
30054 <p><i>[
30055 Batavia (2009-05):
30056 ]</i></p>
30057
30058 <blockquote>
30059 We agree with the direction of the proposed resolution.
30060 Move to NAD Editorial.
30061 </blockquote>
30062
30063
30064
30065 <p><b>Proposed resolution:</b></p>
30066 <p>
30067 Add a note to 20.11.5.1 [time.clock.system], p2:
30068 </p>
30069 <blockquote>
30070 -2- <tt>system_clock::duration::min() &lt; 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>
30072 </blockquote>
30073
30074
30075
30076
30077
30078 <hr>
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:
30086
30087 <blockquote>
30088 .... All intermediate computations shall be
30089 carried out in the widest possible representation... .
30090 </blockquote>
30091
30092 <p>
30093 So ignoring
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.
30098 </p>
30099
30100 <p>
30101 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>.
30102 </p>
30103
30104 <p><i>[
30105 Howard adds:
30106 ]</i></p>
30107
30108
30109 <blockquote>
30110 <p>
30111 The intent of this remark is that intermediate computations are carried out
30112 using:
30113 </p>
30114
30115 <blockquote><pre>common_type&lt;typename ToDuration::rep, Rep, intmax_t&gt;::type
30116 </pre></blockquote>
30117
30118 <p>
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?
30122 </p>
30123 </blockquote>
30124
30125 <p><i>[
30126 Batavia (2009-05):
30127 ]</i></p>
30128
30129 <blockquote>
30130 <p>
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.
30133 </p>
30134 <p>
30135 Move to NAD.
30136 </p>
30137 </blockquote>
30138
30139
30140
30141 <p><b>Proposed resolution:</b></p>
30142 <p>
30143 </p>
30144
30145
30146
30147
30148
30149 <hr>
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>
30156 <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.
30160 </p>
30161
30162 <p>
30163 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>.
30164 </p>
30165
30166 <p><i>[
30167 2009-05-10 Howard adds:
30168 ]</i></p>
30169
30170
30171 <blockquote>
30172 <p>
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>.
30177 </p>
30178 </blockquote>
30179
30180 <p><i>[
30181 Batavia (2009-05):
30182 ]</i></p>
30183
30184 <blockquote>
30185 <p>
30186 Pete suggests that this could be resolved
30187 by rephrasing the Remarks to Notes.
30188 </p>
30189 <p>
30190 Move to NAD Editorial.
30191 </p>
30192 </blockquote>
30193
30194
30195 <p><b>Proposed resolution:</b></p>
30196 <p>
30197 </p>
30198
30199
30200
30201
30202
30203 <hr>
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>
30210 <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
30216 template names.
30217 </p>
30218
30219 <p><i>[
30220 Post Summit, Anthony provided proposed wording.
30221 ]</i></p>
30222
30223
30224 <p><i>[
30225 2009-05-04 Howard adds:
30226 ]</i></p>
30227
30228
30229 <blockquote>
30230 <p>
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.
30241 </p>
30242
30243 <p>
30244 For example, here is code that I once wrote in testing out the usability of
30245 this facility:
30246 </p>
30247
30248 <blockquote><pre>template &lt;class Clock, class Duration&gt;
30249 void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
30250 {
30251     typename Clock::<b>time_point now</b> = Clock::now();
30252     if (t &gt; now)
30253     {
30254         typedef typename std::common_type
30255         &lt;
30256             Duration,
30257             typename std::chrono::system_clock::<b>duration</b>
30258         &gt;::type CD;
30259         typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
30260
30261         CD d = t - now;
30262         ID us = duration_cast&lt;ID&gt;(d);
30263         if (us &lt; d)
30264             ++us;
30265         ...
30266     }
30267 }
30268 </pre></blockquote>
30269
30270 <p>
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>:
30273 </p>
30274
30275 <blockquote><pre>template &lt;class Clock, class Duration&gt;
30276 void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
30277 {
30278     typename Clock::<b>time_point<font color="#C80000">_type</font></b> now = Clock::now();
30279     if (t &gt; now)
30280     {
30281         typedef typename std::common_type
30282         &lt;
30283             Duration,
30284             typename std::chrono::system_clock::<b>duration<font color="#C80000">_type</font></b>
30285         &gt;::type CD;
30286         typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
30287
30288         CD d = t - now;
30289         ID us = duration_cast&lt;ID&gt;(d);
30290         if (us &lt; d)
30291             ++us;
30292         ...
30293     }
30294 }
30295 </pre></blockquote>
30296
30297 <p>
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>.
30301 </p>
30302 <blockquote>
30303 That is, the current proposed wording would put the WP into an inconsistent state.
30304 </blockquote>
30305 <p>
30306 In contrast,
30307 the current WP has been implemented and I've received very favorable feedback
30308 from people using this interface in real-world code.
30309 </p>
30310
30311 </blockquote>
30312
30313 <p><i>[
30314 Batavia (2009-05):
30315 ]</i></p>
30316
30317 <blockquote>
30318 <p>
30319 Bill agrees that distinct names should be used for distinct kinds of entities.
30320 </p>
30321 <p>
30322 Walter would prefer not to suffix type names,
30323 especially for such well-understood terms as "duration".
30324 </p>
30325 <p>
30326 Howard reminds us that the proposed resolution is incomplete, per his comment
30327 in the issue.
30328 </p>
30329 <p>
30330 Move to Open.
30331 </p>
30332 </blockquote>
30333
30334 <p><i>[
30335 2009-06-07 Howard adds:
30336 ]</i></p>
30337
30338
30339 <blockquote>
30340 <p>
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.
30344 </p>
30345
30346 <blockquote><pre>template&lt;class Category, class T, class Distance = ptrdiff_t,
30347          class Pointer = T*, class Reference = T&amp;&gt;
30348 struct <b>iterator</b>
30349 {
30350     ...
30351 };
30352
30353 template &lt;BidirectionalIterator Iter&gt;
30354 class <b>reverse_iterator</b>
30355 {
30356     ...
30357 };
30358
30359 template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
30360     requires NothrowDestructible&lt;T&gt;
30361 class list
30362 {
30363 public:
30364     typedef <i>implementation-defined</i>     <b>iterator</b>;
30365     ...
30366     typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator</b>;
30367     ...
30368 };
30369 </pre></blockquote>
30370
30371 <p>
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.
30375 </p>
30376
30377 <p>
30378 Would we really be doing programmers a favor by renaming these nested types?
30379 </p>
30380
30381 <blockquote><pre>template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
30382     requires NothrowDestructible&lt;T&gt;
30383 class list
30384 {
30385 public:
30386     typedef <i>implementation-defined</i>     <b>iterator_type</b>;
30387     ...
30388     typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator_type</b>;
30389     ...
30390 };
30391 </pre></blockquote>
30392
30393 <p>
30394 I submit that such design contributes to needless verbosity which ends up
30395 reducing readability.
30396 </p>
30397 </blockquote>
30398
30399 <p><i>[
30400 2009-10 Santa Cruz:
30401 ]</i></p>
30402
30403
30404 <blockquote>
30405 Mark as NAD.  No concensus for changing the WP.
30406 </blockquote>
30407
30408
30409
30410 <p><b>Proposed resolution:</b></p>
30411 <p>
30412 Change 20.11 [time]:
30413 </p>
30414
30415 <blockquote><pre>...
30416 template &lt;class Clock, class Duration = typename Clock::duration<ins>_type</ins>&gt; class time_point;
30417 ...
30418 </pre></blockquote>
30419
30420 <p>
30421 Change 20.11.1 [time.clock.req]:
30422 </p>
30423
30424 <blockquote>
30425 <table border="1">
30426 <caption>Table 45 -- Clock requirements</caption>
30427 <tbody><tr>
30428 <th>Expression</th>
30429 <th>Return type</th>
30430 <th>Operational semantics</th>
30431 </tr>
30432 <tr>
30433 <td>...</td>
30434 <td>...</td>
30435 <td>...</td>
30436 </tr>
30437 <tr>
30438 <td><tt>C1::duration<ins>_type</ins></tt></td>
30439 <td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
30440 <td>The native <tt>duration</tt> type of the clock.</td>
30441 </tr>
30442 <tr>
30443 <td><tt>C1::time_point<ins>_type</ins></tt></td>
30444 <td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration<ins>_type</ins>&lt;</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>
30451 </tr>
30452 <tr>
30453 <td>...</td>
30454 <td>...</td>
30455 <td>...</td>
30456 </tr>
30457 <tr>
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 
30462 in time.
30463 </td>
30464 </tr>
30465 </tbody></table>
30466 </blockquote>
30467
30468 <p>
30469 Change 20.11.5.1 [time.clock.system]:
30470 </p>
30471
30472 <blockquote>
30473 <p>
30474 -1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
30475 </p>
30476
30477 <blockquote><pre>class system_clock { 
30478 public: 
30479   typedef <i>see below</i> rep; 
30480   typedef ratio&lt;<i>unspecified</i>, <i>unspecified</i>&gt; period; 
30481   typedef chrono::duration&lt;rep, period&gt; duration<ins>_type</ins>; 
30482   typedef chrono::time_point&lt;system_clock&gt; time_point<ins>_type</ins>; 
30483   static const bool is_monotonic = <i>unspecified</i> ; 
30484
30485   static time_point<ins>_type</ins> now(); 
30486
30487   // Map to C API 
30488   static time_t to_time_t (const time_point<ins>_type</ins>&amp; t); 
30489   static time_point<ins>_type</ins> from_time_t(time_t t); 
30490 };
30491 </pre></blockquote>
30492
30493 <p>
30494 -2- <tt>system_clock::duration<ins>_type</ins>::min() &lt; system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
30495 </p>
30496
30497 <pre>time_t to_time_t(const time_point<ins>_type</ins>&amp; t);
30498 </pre>
30499
30500 <blockquote>
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>.
30504 </blockquote>
30505
30506 <pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
30507 </pre>
30508
30509 <blockquote>
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>.
30513 </blockquote>
30514 </blockquote>
30515
30516 <p>
30517 Change X [time.clock.monotonic]:
30518 </p>
30519
30520 <blockquote><pre>class monotonic_clock { 
30521 public: 
30522   typedef <i>unspecified</i>                                rep; 
30523   typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
30524   typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
30525   typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
30526   static const bool is_monotonic =                   true; 
30527
30528   static time_point<ins>_type</ins> now();
30529 };
30530 </pre></blockquote>
30531
30532 <p>
30533 Change 20.11.5.3 [time.clock.hires]:
30534 </p>
30535
30536 <blockquote><pre>class high_resolution_clock { 
30537 public: 
30538   typedef <i>unspecified</i>                                rep; 
30539   typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
30540   typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
30541   typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
30542   static const bool is_monotonic =                   true; 
30543
30544   static time_point<ins>_type</ins> now();
30545 };
30546 </pre></blockquote>
30547
30548
30549
30550
30551
30552
30553 <hr>
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>
30560 <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?
30567 </p>
30568
30569 <p><i>[
30570 Summit:
30571 ]</i></p>
30572
30573
30574 <blockquote>
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
30576 related issues.
30577 </blockquote>
30578
30579 <p><i>[
30580 2009-08-01 Howard adds:
30581 ]</i></p>
30582
30583
30584 <blockquote>
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
30587 it moves to WP).
30588 </blockquote>
30589
30590 <p><i>[
30591 2009-10 Santa Cruz:
30592 ]</i></p>
30593
30594
30595 <blockquote>
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>.
30597 </blockquote>
30598
30599
30600
30601 <p><b>Proposed resolution:</b></p>
30602 <p>
30603 </p>
30604
30605
30606
30607
30608
30609 <hr>
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>
30616 <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
30620 exist.
30621 </p>
30622
30623 <p><i>[
30624 Summit:
30625 ]</i></p>
30626
30627
30628 <blockquote>
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
30630 related issues.
30631 </blockquote>
30632
30633 <p><i>[
30634 2009-08-01 Howard adds:
30635 ]</i></p>
30636
30637
30638 <blockquote>
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
30641 it moves to WP).
30642 </blockquote>
30643
30644 <p><i>[
30645 2009-10 Santa Cruz:
30646 ]</i></p>
30647
30648
30649 <blockquote>
30650 Leave open, but expect to be fixed by N2969 revision that Detlef is writing.
30651 </blockquote>
30652
30653 <p><i>[
30654 2009-11-18 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
30655 Rationale added below.
30656 ]</i></p>
30657
30658
30659
30660
30661 <p><b>Proposed resolution:</b></p>
30662 <p>
30663 </p>
30664
30665
30666 <p><b>Rationale:</b></p>
30667 <p>
30668 <tt>condition_variable::wait_for</tt> no longer refers to
30669 <tt>monotonic_clock</tt>, so this issue is moot.
30670 </p>
30671
30672
30673
30674
30675
30676 <hr>
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>
30684 <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.
30690 </p>
30691
30692 <p><i>[
30693 Summit:
30694 ]</i></p>
30695
30696 <blockquote>
30697 Move to open. Related to conceptualization and should probably be
30698 tackled as part of that.
30699 </blockquote>
30700
30701 <p><i>[
30702 2009-10 Santa Cruz:
30703 ]</i></p>
30704
30705
30706 <blockquote>
30707 <p>
30708 Would be OK to leave it as is for time constraints, could loosen later.
30709 </p>
30710
30711 <p>
30712 Mark as NAD Future.
30713 </p>
30714 </blockquote>
30715
30716
30717
30718 <p><b>Proposed resolution:</b></p>
30719 <p>
30720 </p>
30721
30722
30723
30724
30725
30726 <hr>
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>
30733 <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>
30736 was removed in
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).
30739 </p>
30740
30741 <p><i>[
30742 Batavia (2009-05):
30743 ]</i></p>
30744
30745 <blockquote>
30746 Move to NAD Editorial.
30747 </blockquote>
30748
30749
30750 <p><b>Proposed resolution:</b></p>
30751 <p>
30752 Restore the non-normative note. It might need to be expressed in terms of concepts.
30753 </p>
30754
30755
30756
30757
30758
30759 <hr>
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>
30765 <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?"
30768 </p>
30769 <p>
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.
30775 </p>
30776
30777 <p><i>[
30778 Post Summit:
30779 ]</i></p>
30780
30781
30782 <blockquote>
30783 Recommend Review.
30784 </blockquote>
30785
30786 <p><i>[
30787 Batavia (2009-05):
30788 ]</i></p>
30789
30790 <blockquote>
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.
30796 </blockquote>
30797
30798 <p><i>[
30799 2009-05-21 Beman adds:
30800 ]</i></p>
30801
30802
30803 <blockquote>
30804 My mistake. Christopher and Bill are correct and the issue should be
30805 NAD. The function is needed by users.
30806 </blockquote>
30807
30808 <p><i>[
30809 2009-07-21 Christopher Kohlhoff adds rationale for <tt>make_error_code</tt>:
30810 ]</i></p>
30811
30812
30813 <blockquote>
30814 <p>
30815 Users (and indeed library implementers) may need to use the
30816 <tt>errc</tt> codes in portable code. For example:
30817 </p>
30818
30819 <blockquote><pre>void do_foo(error_code&amp; ec)
30820 {
30821 #if defined(_WIN32)
30822   // Windows implementation ...
30823 #elif defined(linux)
30824   // Linux implementation ...
30825 #else
30826   // do_foo not supported on this platform
30827   ec = make_error_code(errc::not_supported);
30828 #endif
30829 }
30830 </pre></blockquote>
30831 </blockquote>
30832
30833 <p><i>[
30834 2009 Santa Cruz:
30835 ]</i></p>
30836
30837
30838 <blockquote>
30839 Moved to NAD.
30840 </blockquote>
30841
30842
30843
30844 <p><b>Proposed resolution:</b></p>
30845 <p>
30846 Change System error support 19.5 [syserr], Header <tt>&lt;system_error&gt;</tt>
30847 synopsis, as indicated:
30848 </p>
30849
30850 <blockquote><pre><del>error_code make_error_code(errc e);</del>
30851 error_condition make_error_condition(errc e);
30852 </pre></blockquote>
30853
30854 <p>
30855 Delete from Class error_code non-member functions
30856 19.5.2.5 [syserr.errcode.nonmembers]:
30857 </p>
30858
30859 <blockquote><pre><del>error_code make_error_code(errc e);</del>
30860 </pre>
30861 <blockquote>
30862 <del><i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
30863 generic_category)</tt>.</del>
30864 </blockquote>
30865 </blockquote>
30866
30867
30868
30869
30870
30871
30872 <hr>
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>
30880 <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>.
30891 </p>
30892
30893 <p>
30894 Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"? 
30895 </p>
30896
30897 <p><i>[
30898 Batavia (2009-05):
30899 ]</i></p>
30900
30901 <blockquote>
30902 Move to NAD Editorial.
30903 </blockquote>
30904
30905
30906 <p><b>Proposed resolution:</b></p>
30907
30908 <p>
30909 Change Exception Propagation 18.8.5 [propagation]:
30910 </p>
30911 <blockquote>
30912 <tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>,
30913 <tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>.
30914 </blockquote>
30915
30916 <p>
30917 Change Class template reference_wrapper 20.8.4 [refwrap]:
30918 </p>
30919 <blockquote>
30920 <tt>reference_wrapper&lt;T&gt;</tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>.
30921 </blockquote>
30922 <p>
30923 Change Placeholders 20.8.10.1.3 [func.bind.place]:
30924 </p>
30925 <blockquote>
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.
30927 </blockquote>
30928 <p>
30929 Change Class template shared_ptr 20.9.10.2 [util.smartptr.shared]:
30930 </p>
30931 <blockquote>
30932 Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
30933 </blockquote>
30934 <p>
30935 Change Class template weak_ptr 20.9.10.3 [util.smartptr.weak]:
30936 </p>
30937 <blockquote>
30938 Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
30939 </blockquote>
30940 <p>
30941 Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
30942 </p>
30943 <blockquote>
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.
30945 </blockquote>
30946 <p>
30947 Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
30948 </p>
30949 <blockquote>
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>.
30952 </blockquote>
30953
30954 <p>
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.
30959 </p>
30960
30961
30962
30963
30964
30965
30966 <hr>
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>
30973 <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.
30980 </p>
30981
30982 <p><i>[
30983 Batavia (2009-05):
30984 ]</i></p>
30985
30986 <blockquote>
30987 We agree with the intent of the proposed resolution.
30988 Move to NAD Editorial.
30989 </blockquote>
30990
30991
30992 <p><b>Proposed resolution:</b></p>
30993 <p>
30994 Change D.12.1 [auto.ptr], paragraph 3:
30995 </p>
30996
30997 <blockquote>
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
31011 behavior.</del>
31012
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>]
31018 </blockquote>
31019
31020
31021
31022
31023
31024 <hr>
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>
31030 <p>
31031 The synopsis given in 23.5.3.1 [stack.defn] does not show up
31032 </p>
31033
31034 <blockquote><pre>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);
31035 requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);
31036 </pre></blockquote>
31037
31038 <p>
31039 although the other container adaptors do provide corresponding
31040 members.
31041 </p>
31042
31043 <p><i>[
31044 Batavia (2009-05):
31045 ]</i></p>
31046
31047 <blockquote>
31048 <p>
31049 We agree with the proposed resolution.
31050 </p>
31051 <p>
31052 Move to Tentatively Ready.
31053 </p>
31054 </blockquote>
31055
31056 <p><i>[
31057 2009-07 Frankfurt
31058 ]</i></p>
31059
31060
31061 <blockquote>
31062 Moved from Tentatively Ready to Open only because the wording needs to be
31063 tweaked for concepts removal.
31064 </blockquote>
31065
31066 <p><i>[
31067 2009-08-18 Daniel updates the wording and Howard sets to Review.
31068 ]</i></p>
31069
31070
31071 <p><i>[
31072 2009-08-23 Howard adds:
31073 ]</i></p>
31074
31075
31076 <blockquote>
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
31078 style.
31079 </blockquote>
31080
31081 <p><i>[
31082 2009-10 Santa Cruz:
31083 ]</i></p>
31084
31085
31086 <blockquote>
31087 Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>.
31088 </blockquote>
31089
31090
31091
31092 <p><b>Proposed resolution:</b></p>
31093 <p>
31094 In the class stack synopsis of 23.5.3.1 [stack.defn] insert:
31095 </p>
31096
31097 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
31098 class stack {
31099   [..]
31100   explicit stack(const Container&amp;);
31101   explicit stack(Container&amp;&amp; = Container());
31102   <ins>stack(stack&amp;&amp; s) : c(std::move(s.c)) {}</ins>
31103   <ins>stack&amp; operator=(stack&amp;&amp; s) { c = std::move(s.c); return *this; }</ins>
31104   [..]
31105 };
31106 </pre></blockquote>
31107
31108
31109
31110
31111
31112
31113
31114
31115 <hr>
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>
31122 <p>
31123 The new concepts for the insert iterators mandate an extra copy when
31124 inserting an lvalue:
31125 </p>
31126
31127 <blockquote><pre>requires CopyConstructible&lt;Cont::value_type&gt;
31128   back_insert_iterator&lt;Cont&gt;&amp; 
31129   operator=(const Cont::value_type&amp; value);
31130 </pre>
31131 <blockquote>
31132 -1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
31133 </blockquote>
31134 </blockquote>
31135
31136 <p>
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
31139 rvalues:
31140 </p>
31141
31142 <blockquote><pre>concept BackInsertionContainer&lt;typename C&gt; : Container&lt;C&gt; { 
31143   void push_back(C&amp;, value_type&amp;&amp;); 
31144 }
31145 </pre></blockquote>
31146
31147 <p>
31148 Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
31149 fails to concept check.
31150 </p>
31151
31152 <p>
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:
31156 </p>
31157
31158 <blockquote><pre>concept BackInsertionContainer&lt;typename C, typename Value = C::value_type&amp;&amp;&gt;
31159   : Container&lt;C&gt; { 
31160      void push_back(C&amp;, Value); 
31161 }
31162 </pre></blockquote>
31163
31164 <p>
31165 This allows the assignment operator to be adjusted appropriately:
31166 </p>
31167
31168 <blockquote><pre>requires BackInsertionContainer&lt;Cont, Cont::value_type const&amp;&gt; &amp;&amp;
31169          CopyConstructible&lt;Cont::value_type&gt;
31170   back_insert_iterator&lt;Cont&gt;&amp; 
31171   operator=(const Cont::value_type&amp; value);
31172 </pre>
31173 <blockquote>
31174 -1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
31175 </blockquote>
31176 </blockquote>
31177
31178 <p><i>[
31179 We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
31180 ]</i></p>
31181
31182
31183 <p><i>[
31184 Solution and wording collaborated on by Doug and Howard.
31185 ]</i></p>
31186
31187
31188 <p><i>[
31189 Batavia (2009-05):
31190 ]</i></p>
31191
31192 <blockquote>
31193 <p>
31194 Howard notes that "these operations behaved efficiently until concepts were added."
31195 </p>
31196 <p>
31197 Alisdair is uncertain that the proposed resolution is syntactically correct.
31198 </p>
31199 <p>
31200 Move to Open, and recommend the issue be deferred until after the next
31201 Committee Draft is issued.
31202 </p>
31203 </blockquote>
31204
31205 <p><i>[
31206 2009-10 Santa Cruz:
31207 ]</i></p>
31208
31209
31210 <blockquote>
31211 NAD, solved by the removal of concepts.
31212 </blockquote>
31213
31214
31215
31216 <p><b>Proposed resolution:</b></p>
31217 <p>
31218 Change  [container.concepts.free]:
31219 </p>
31220
31221 <blockquote>
31222 <pre>concept FrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31223     : Container&lt;C&gt; { 
31224   void push_front(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31225
31226   axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
31227     x == (push_front(c, x), front(c)); 
31228   } 
31229 }
31230 </pre>
31231
31232 <p>...</p>
31233
31234 <pre>concept BackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31235     : Container&lt;C&gt; { 
31236   void push_back(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31237 }
31238 </pre>
31239
31240 <p>...</p>
31241
31242 <pre>concept InsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31243     : Container&lt;C&gt; { 
31244   iterator insert(C&amp;, const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31245
31246   axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
31247     v == *insert(c, position, v); 
31248   } 
31249 }
31250 </pre>
31251
31252 </blockquote>
31253
31254 <p>
31255 Change  [container.concepts.member]:
31256 </p>
31257
31258 <blockquote>
31259 <pre>auto concept MemberFrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31260     : MemberContainer&lt;C&gt; { 
31261   void C::push_front(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31262
31263   axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
31264     x == (c.push_front(x), c.front()); 
31265   } 
31266 }
31267 </pre>
31268
31269 <p>...</p>
31270
31271 <pre>auto concept MemberBackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31272     : MemberContainer&lt;C&gt; { 
31273   void C::push_back(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31274 }
31275 </pre>
31276
31277 <p>...</p>
31278
31279 <pre>auto concept MemberInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
31280     : MemberContainer&lt;C&gt; { 
31281   iterator C::insert(const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
31282
31283   axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
31284     v == *c.insert(position, v); 
31285   } 
31286 }
31287 </pre>
31288 </blockquote>
31289
31290 <p>
31291 Change  [container.concepts.maps]:
31292 </p>
31293
31294 <blockquote>
31295 <pre>template &lt;MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
31296 concept_map FrontInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
31297   typedef Container&lt;C&gt;::value_type value_type;
31298
31299   void push_front(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_front(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
31300 }
31301 </pre>
31302
31303 <p>...</p>
31304
31305 <pre>template &lt;MemberBackInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
31306 concept_map BackInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
31307   typedef Container&lt;C&gt;::value_type value_type;
31308
31309   void push_back(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_back(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
31310 }
31311 </pre>
31312
31313 <p>...</p>
31314
31315 <pre>template &lt;MemberInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
31316 concept_map InsertionContainer&lt;C<ins>, Value</ins>&gt; { 
31317   typedef Container&lt;C&gt;::value_type value_type;
31318   Container&lt;C&gt;::iterator insert(C&amp; c, Container&lt;C&gt;::const_iterator i, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) 
31319   { return c.insert(i, static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
31320 }
31321 </pre>
31322
31323 </blockquote>
31324
31325 <p>
31326 Change 24.5.2.1 [back.insert.iterator]:
31327 </p>
31328
31329 <blockquote><pre>template &lt;BackInsertionContainer Cont&gt; 
31330 class back_insert_iterator {
31331   ...
31332   requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31333            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31334     back_insert_iterator&lt;Cont&gt;&amp; 
31335       operator=(const Cont::value_type&amp; value);
31336   ...
31337 </pre></blockquote>
31338
31339 <p>
31340 Change 24.5.2.2.2 [back.insert.iter.op=]:
31341 </p>
31342
31343 <blockquote>
31344 <pre>requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31345          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31346   back_insert_iterator&lt;Cont&gt;&amp; 
31347     operator=(const Cont::value_type&amp; value);
31348 </pre>
31349 <blockquote>
31350 -1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
31351 </blockquote>
31352 </blockquote>
31353
31354 <p>
31355 Change 24.5.2.3 [front.insert.iterator]:
31356 </p>
31357
31358 <blockquote><pre>template &lt;FrontInsertionContainer Cont&gt; 
31359 class front_insert_iterator {
31360   ...
31361   requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31362            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31363     front_insert_iterator&lt;Cont&gt;&amp; 
31364       operator=(const Cont::value_type&amp; value);
31365   ...
31366 </pre></blockquote>
31367
31368 <p>
31369 Change 24.5.2.4.2 [front.insert.iter.op=]:
31370 </p>
31371
31372 <blockquote>
31373 <pre>requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31374          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31375   front_insert_iterator&lt;Cont&gt;&amp; 
31376     operator=(const Cont::value_type&amp; value);
31377 </pre>
31378 <blockquote>
31379 -1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
31380 </blockquote>
31381 </blockquote>
31382
31383 <p>
31384 Change 24.5.2.5 [insert.iterator]:
31385 </p>
31386
31387 <blockquote><pre>template &lt;InsertionContainer Cont&gt; 
31388 class insert_iterator {
31389   ...
31390   requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31391            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31392     insert_iterator&lt;Cont&gt;&amp; 
31393       operator=(const Cont::value_type&amp; value);
31394   ...
31395 </pre></blockquote>
31396
31397 <p>
31398 Change 24.5.2.6.2 [insert.iter.op=]:
31399 </p>
31400
31401 <blockquote>
31402 <pre>requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
31403          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
31404   insert_iterator&lt;Cont&gt;&amp; 
31405     operator=(const Cont::value_type&amp; value);
31406 </pre>
31407 <blockquote>
31408 <p>
31409 -1- <i>Effects:</i>
31410 </p>
31411 <blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>); 
31412 ++iter;
31413 </pre></blockquote>
31414 </blockquote>
31415 </blockquote>
31416
31417
31418
31419
31420
31421
31422 <hr>
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>
31428 <p>
31429 24.5.3 [move.iterators] has an incorrect example:
31430 </p>
31431
31432 <blockquote>
31433 <p>
31434 -2- [<i>Example:</i>
31435 </p>
31436
31437 <blockquote><pre>set&lt;string&gt; s; 
31438 // populate the set s 
31439 vector&lt;string&gt; v1(s.begin(), s.end());          // copies strings into v1 
31440 vector&lt;string&gt; v2(make_move_iterator(s.begin()), 
31441                   make_move_iterator(s.end())); // moves strings into v2
31442 </pre></blockquote>
31443
31444 <p>
31445 <i>-- end example</i>]
31446 </p>
31447 </blockquote>
31448
31449 <p>
31450 One can not move from a <tt>set</tt> because the iterators return <tt>const</tt>
31451 references.
31452 </p>
31453
31454 <p><i>[
31455 Batavia (2009-05):
31456 ]</i></p>
31457
31458 <blockquote>
31459 We agree with the proposed resolution. Move to NAD Editorial.
31460 </blockquote>
31461
31462
31463
31464 <p><b>Proposed resolution:</b></p>
31465 <p>
31466 Change 24.5.3 [move.iterators]/2:
31467 </p>
31468
31469 <blockquote>
31470 <p>
31471 -2- [<i>Example:</i>
31472 </p>
31473
31474 <blockquote><pre><del>set</del><ins>list</ins>&lt;string&gt; s; 
31475 // populate the <del>set</del><ins>list</ins> s 
31476 vector&lt;string&gt; v1(s.begin(), s.end());          // copies strings into v1 
31477 vector&lt;string&gt; v2(make_move_iterator(s.begin()), 
31478                   make_move_iterator(s.end())); // moves strings into v2
31479 </pre></blockquote>
31480
31481 <p>
31482 <i>-- end example</i>]
31483 </p>
31484 </blockquote>
31485
31486
31487
31488
31489
31490 <hr>
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>
31497 <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.
31502 </p>
31503
31504 <p>
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
31507 being destroyed.
31508 </p>
31509
31510 <p>
31511 Consider:
31512 </p>
31513
31514 <blockquote><pre>//Suppose mutex.lock() throws "owner_dead"
31515 unique_lock ul(&amp;mutex);
31516 //mutex left locked if "owner_dead" is thrown
31517 </pre></blockquote>
31518
31519 <p>
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.
31524 </p>
31525
31526 <ol>
31527 <li>
31528 For <tt>state_not_recoverable</tt> add it to the list of Error conditions:
31529 </li>
31530 <li>
31531 For <tt>owner_dead</tt>, no proposed resolution.
31532 </li>
31533 </ol>
31534
31535 <p><i>[
31536 Summit:
31537 ]</i></p>
31538
31539
31540 <blockquote>
31541 Not a defect. Handling these error conditions is an implementation
31542 detail and must be handled below the C++ interface.
31543 </blockquote>
31544
31545
31546
31547 <p><b>Proposed resolution:</b></p>
31548
31549 <p>
31550 Add to 30.4.1 [thread.mutex.requirements], p12:
31551 </p>
31552
31553 <blockquote>
31554 <p>
31555 -12- <i>Error conditions:</i>
31556 </p>
31557
31558 <ul>
31559 <li>
31560 <tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change 
31561 the state of the mutex.
31562 </li>
31563 <li>
31564 <tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able 
31565 to detect it.
31566 </li>
31567 <li>
31568 <tt>device_or_resource_busy</tt> --  if the mutex is already locked and blocking is not possible.
31569 </li>
31570 <li>
31571 <ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins>
31572 </li>
31573 </ul>
31574 </blockquote>
31575
31576
31577
31578
31579
31580 <hr>
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>
31587 <p>
31588 X [concept.comparison] p2:
31589 </p>
31590 <p>
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.
31594 </p>
31595
31596 <b>
31597 Original proposed resolution:
31598 </b>
31599
31600 <p>
31601 Change the definition of <tt>Reflexivity</tt> in X [concept.comparison]:
31602 </p>
31603
31604 <blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; }
31605 </pre></blockquote>
31606
31607 <p><i>[
31608 Post Summit:
31609 ]</i></p>
31610
31611
31612 <blockquote>
31613 <p>
31614 Alisdair: I was wrong.
31615 </p>
31616 <p>
31617 Recommend NAD.
31618 </p>
31619 </blockquote>
31620
31621
31622
31623 <p><b>Proposed resolution:</b></p>
31624 <p>
31625 NAD.
31626 </p>
31627
31628
31629
31630
31631
31632 <hr>
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>
31640 <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.
31644 </p>
31645 <p>
31646 Do we need some text in clause 17 prohibitting use of late_check in library
31647 template definitions unless otherwise documented?
31648 </p>
31649
31650 <p><i>[
31651 Doug adds:
31652 ]</i></p>
31653
31654
31655 <blockquote>
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).
31662 </blockquote>
31663
31664 <p><i>[
31665 Batavia (2009-05):
31666 ]</i></p>
31667
31668 <blockquote>
31669 Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
31670 </blockquote>
31671
31672
31673 <p><b>Proposed resolution:</b></p>
31674
31675
31676
31677
31678
31679 <hr>
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>
31687 <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)
31690 </p>
31691
31692 <p><i>[
31693 Batavia (2009-05):
31694 ]</i></p>
31695
31696 <blockquote>
31697 The proposed wording seems to go too far.
31698 Move back to Open.
31699 </blockquote>
31700
31701 <p><i>[
31702 2009-07 Frankfurt:
31703 ]</i></p>
31704
31705
31706 <blockquote>
31707 <p>
31708 Howard to add NB reference to the description of this issue.
31709 </p>
31710 <p>
31711 Move to NAD. This comment is informative and not normative by the use of
31712 the word "are" instead of the word "shall."
31713 </p>
31714 <p>
31715 A note linking to Annex D would help clarify the intention, here.
31716 </p>
31717 <p>
31718 Robert to Open a separate issue proposing that the standard C headers be
31719 undeprecated, for the purpose of clarifying the standard.
31720 </p>
31721 </blockquote>
31722
31723 <p><i>[
31724 2009-07-22 Bill modified the proposed wording with a clarifying footnote.
31725 ]</i></p>
31726
31727
31728
31729
31730 <p><b>Proposed resolution:</b></p>
31731 <p>
31732 Add a footnote to 17.6.1.1 [contents], p2:
31733 </p>
31734
31735 <blockquote>
31736 <p>
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>.
31740 </p>
31741
31742 <p><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.
31747 </ins></p>
31748 </blockquote>
31749
31750
31751
31752
31753
31754
31755 <hr>
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>
31761 <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.
31766 </p>
31767
31768 <p><i>[
31769 Batavia (2009-05):
31770 ]</i></p>
31771
31772 <blockquote>
31773 Agree with the recommended NAD resolution.
31774 </blockquote>
31775
31776
31777 <p><b>Proposed resolution:</b></p>
31778 <p>
31779 Recommend NAD.  The text in 17.5.1.3 [structure.requirements] is
31780 perfectly clear.
31781 </p>
31782
31783
31784
31785
31786
31787 <hr>
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>
31795 <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>.
31798 </p>
31799 <p>
31800 We also don't account for whether that operation modifies <tt>x</tt> or not, and
31801 we need to.
31802 </p>
31803
31804 <p><i>[
31805 Batavia (2009-05):
31806 ]</i></p>
31807
31808 <blockquote>
31809 Move to Open, pending proposed wording from Dave for further
31810 review.
31811 </blockquote>
31812
31813
31814
31815 <p><i>[
31816 2010 Rapperswil:
31817 ]</i></p>
31818
31819
31820 <blockquote>
31821 Move to NAD.  We define what we expect from a moved-from object in Table 34 [movesconstructible].
31822 </blockquote>
31823
31824
31825
31826 <p><b>Proposed resolution:</b></p>
31827 <p>
31828 </p>
31829
31830
31831
31832
31833
31834 <hr>
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>
31841 <p>
31842 <b>Addresses UK 296</b>
31843 </p>
31844
31845 <p>
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:
31849 </p>
31850 <blockquote>
31851 <table>
31852 <tbody><tr>
31853 <td valign="top">
31854 <tt>adjacent_find(begin,&nbsp;end,&nbsp;less&lt;double&gt;)</tt>
31855 </td>
31856 <td>
31857 Find the first
31858 place where a range is not ordered in decreasing order - in use to check
31859 for sorted ranges.
31860 </td>
31861 </tr>
31862 <tr>
31863 <td valign="top">
31864 <tt>adjacent_find(begin,&nbsp;end,&nbsp;DistanceBiggerThan(6)&nbsp;)&nbsp;)</tt>
31865 </td>
31866 <td>
31867 Find the first
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.
31871 </td>
31872 </tr>
31873 </tbody></table>
31874 </blockquote>
31875
31876 <p>
31877 A number of books use predicate which are not equivalence relations in
31878 examples, including "Thinking in C++" and "C++ Primer".
31879 </p>
31880
31881 <p>
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.
31884 </p>
31885
31886
31887
31888 <p><b>Proposed resolution:</b></p>
31889 <p>
31890 Change the definition of adjacent_find in the synopsis of 25 [algorithms]
31891 and 25.2.8 [alg.adjacent.find] to:
31892 </p>
31893
31894 <blockquote><pre>template&lt;ForwardIterator Iter&gt; 
31895   requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;Iter::value_type<ins>, Iter::value_type</ins>&gt;
31896   Iter adjacent_find(Iter first, Iter last);
31897
31898 template&lt;ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins>&lt;auto, Iter::value_type<ins>, Iter::value_type</ins>&gt; Pred&gt; 
31899   requires CopyConstructible&lt;Pred&gt; 
31900   Iter adjacent_find(Iter first, Iter last, Pred pred);
31901 </pre></blockquote>
31902
31903
31904
31905
31906
31907 <hr>
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>
31915
31916 <p><b>Addresses UK 78</b></p>
31917
31918 <p>
31919 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>.
31920 </p>
31921
31922 <p>
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>.
31924 </p>
31925 <p>
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
31930 declarations.
31931 </p>
31932 <p>
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 &lt;iterator_concepts&gt;</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.
31940 </p>
31941 <p>
31942 Therefore, I suggest we should require all library headers that make use of
31943 iterator concepts are specifically required to <tt>#include &lt;iterator_concepts&gt;</tt>.
31944 </p>
31945 <p>
31946 At a minimum, the list of headers would be: (assuming all are constrained by
31947 concepts)
31948 </p>
31949 <blockquote><pre>algorithm
31950 array
31951 deque
31952 forward_list
31953 initializer_list
31954 iterator
31955 locale
31956 list
31957 map
31958 memory          // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a> is adopted
31959 memory_concepts
31960 numeric
31961 random
31962 regex
31963 set
31964 string
31965 tuple
31966 unordered_map
31967 unordered_set
31968 utility
31969 vector
31970 </pre></blockquote>
31971
31972 <p><i>[
31973 Ganesh adds:
31974 ]</i></p>
31975
31976
31977 <blockquote>
31978 <p>
31979 The same problems exists for <tt>&lt;memory_concepts&gt;</tt> and
31980 <tt>&lt;container_concepts&gt;</tt>.
31981 </p>
31982 <p>
31983 In order to compile <tt>&lt;vector&gt;</tt> you just need the
31984 definitions of the concepts in <tt>&lt;memory_concepts&gt;</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>&lt;vector&gt;</tt> is pretty useless. Same for
31988 <tt>&lt;tuple&gt;</tt> and <tt>ConstructibleWithAllocator</tt>.
31989 </p>
31990 <p>
31991 Similarly, <tt>&lt;queue&gt;</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.
31994 </p>
31995 <p>
31996 There's a pattern here: if a concept has concept maps "attached", they
31997 should never be separated.
31998 </p>
31999 </blockquote>
32000
32001 <p><i>[
32002 Beman provided the proposed resolution for the May 2009 mailing. He 
32003 comments:
32004 ]</i></p>
32005
32006
32007 <blockquote>
32008
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>
32012
32013 </blockquote>
32014
32015 <p><i>[
32016 Batavia (2009-05):
32017 ]</i></p>
32018
32019 <blockquote>
32020 <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,
32025 e.g.,
32026 </p>
32027 <blockquote>
32028 A C++ header shall provide the names
32029 that are required to be defined in that header.
32030 </blockquote>
32031 <p>
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."
32037 </p>
32038 <p>
32039 Move to Open status.
32040 </p>
32041
32042 </blockquote>
32043
32044 <p><i>[
32045 2009-06-16 Beman updated the proposed resolution:
32046 ]</i></p>
32047
32048
32049 <blockquote>
32050   <ul>
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 
32055     permitted.</li>
32056   </ul>
32057 </blockquote>
32058
32059 <p><i>[
32060 2009-07-15 Beman updated the proposed resolution:
32061 ]</i></p>
32062
32063
32064 <p><i>[
32065 2009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt:
32066 ]</i></p>
32067
32068
32069 <blockquote>
32070 <ul>
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>
32074 </ul>
32075 </blockquote>
32076
32077 <p><i>[
32078 2009-07 Frankfurt:
32079 ]</i></p>
32080
32081
32082 <blockquote>
32083 <p>
32084 Revised Proposed Resolution:
32085 </p>
32086 <p>
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.
32092 </p>
32093 <p>
32094 Alisdair: Does this address the BSI comment?
32095 </p>
32096 <p>
32097 Beman: There were several overlapping comments. I tried to handle them
32098 all with one resolution.
32099 </p>
32100 <p>
32101 Alisdair: I'd prefer to see this closed as NAD and have this resolution
32102 be the subject of some other, new issue.
32103 </p>
32104 <p>
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
32107 issue.
32108 </p>
32109 </blockquote>
32110
32111
32112
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>
32115
32116 <blockquote>
32117
32118 <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>
32125 </p>
32126
32127   <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
32128   any needed definition (3.2).</del></p>
32129 </blockquote>
32130
32131
32132
32133
32134
32135
32136 <hr>
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>
32143
32144 <p><b>Addresses UK 170</b></p>
32145
32146 <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.
32153 </p>
32154
32155 <p><i>[
32156 Batavia (2009-05):
32157 ]</i></p>
32158
32159 <blockquote>
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.
32163 </blockquote>
32164
32165 <p><i>[
32166 2009-07-06 Beman notes:
32167 ]</i></p>
32168
32169
32170 <blockquote>
32171 <p>
32172 This issue
32173 adds a header <tt>&lt;std&gt;</tt>.
32174 </p>
32175 <p>
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>&lt;std-all&gt;</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.
32183 </p>
32184 <p>
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>.
32187 </p>
32188 </blockquote>
32189
32190 <p><i>[
32191 2009-07-06 Howard:  I've pulled this issue back to Review.
32192 ]</i></p>
32193
32194
32195 <p><i>[
32196 2009-07 Frankfurt
32197 ]</i></p>
32198
32199
32200 <blockquote>
32201 No consensus for change.
32202 </blockquote>
32203
32204
32205
32206 <p><b>Proposed resolution:</b></p>
32207 <p>
32208 Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
32209 </p>
32210 <blockquote>
32211 An additional header <tt>&lt;std&gt;</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>]
32215 </blockquote>
32216
32217
32218
32219
32220
32221 <hr>
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>
32228
32229 <p><b>Addresses JP 23</b></p>
32230
32231 <p>
32232 There is a freestanding implementation including
32233 <tt>&lt;type_traits&gt;</tt>, <tt>&lt;array&gt;</tt>,
32234 <tt>&lt;ratio&gt;</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
32238 least.
32239 </p>
32240
32241 <p><b>Original proposed resolution</b></p>
32242
32243 <p>
32244 Add <tt>&lt;type_traits&gt;</tt>, <tt>&lt;array&gt;</tt>,
32245 <tt>&lt;ratio&gt;</tt> to Table 15.
32246 </p>
32247
32248 <p><i>[
32249 Summit:
32250 ]</i></p>
32251
32252
32253 <blockquote>
32254 <p>
32255  The <tt>&lt;array&gt;</tt> header has far too many dependencies to require for a
32256 free-standing implementation.
32257 </p>
32258 <p>
32259 The <tt>&lt;ratio&gt;</tt> header would be useful, has no dependencies, but is not
32260 strictly necessary.
32261 </p>
32262 <p>
32263 The <tt>&lt;type_traits&gt;</tt> header is fundamentally a core language facility with a
32264 library interface, so should be supported.
32265 </p>
32266
32267 <p>
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>)
32271 </p>
32272 </blockquote>
32273
32274 <p><i>[
32275 Batavia (2009-05):
32276 ]</i></p>
32277
32278 <blockquote>
32279 Leave in Review status pending a paper on freestanding implementations
32280 by Martin Tasker.
32281 </blockquote>
32282
32283 <p><i>[
32284 2009-07 Frankfurt:
32285 ]</i></p>
32286
32287
32288 <blockquote>
32289 <p>
32290 Move this to NAD.
32291 </p>
32292 <p>
32293 We considered all of the listed headers, and found a compelling case
32294 only for the inclusion of <tt>&lt;type_traits&gt;</tt> in the list of headers required
32295 of a freestanding implementation.
32296 </p>
32297 <p>
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>&lt;type_traits&gt;</tt> into freestanding
32301 implementations.
32302 </p>
32303 </blockquote>
32304
32305
32306
32307 <p><b>Proposed resolution:</b></p>
32308 <p>
32309 Add <tt>&lt;type_traits&gt;</tt> to Table 15.
32310 </p>
32311
32312
32313
32314
32315
32316
32317 <hr>
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>
32323
32324 <p><b>Addresses JP 26</b></p>
32325
32326 <p>
32327 <tt>numeric_limits</tt> [partial specializations] does not use concept.
32328 </p>
32329
32330 <p><i>[
32331 Summit:
32332 ]</i></p>
32333
32334
32335 <blockquote>
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>.
32337 </blockquote>
32338
32339 <p><i>[
32340 Post Summit:
32341 ]</i></p>
32342
32343
32344 <blockquote>
32345 Alisdair recommends NAD as the partial specializations are already
32346 constrained by requirements on the primary template.
32347 </blockquote>
32348
32349 <p><i>[
32350 Batavia (2009-05):
32351 ]</i></p>
32352
32353 <blockquote>
32354 The Working Draft does not in general repeat a primary template's constraints
32355 in any specializations.
32356 Move to NAD.
32357 </blockquote>
32358
32359 <p><i>[
32360 2009-05-25 Howard adds:
32361 ]</i></p>
32362
32363
32364 <blockquote>
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.
32370 </blockquote>
32371
32372
32373 <p><b>Proposed resolution:</b></p>
32374 <p>
32375 Change 18.3.1.1 [numeric.limits]:
32376 </p>
32377
32378 <blockquote><pre>template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;const T&gt;;
32379 template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;volatile T&gt;;
32380 template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;const volatile T&gt;;
32381 </pre></blockquote>
32382
32383
32384
32385
32386
32387
32388 <hr>
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>
32395
32396 <p><b>Addresses JP 29</b></p>
32397
32398 <p>
32399 <tt>throw_with_nested</tt> does not use concept.
32400 </p>
32401
32402 <p><i>[
32403 Summit:
32404 ]</i></p>
32405
32406  
32407 <blockquote>
32408 Agreed.
32409 </blockquote>
32410
32411
32412
32413 <p><b>Proposed resolution:</b></p>
32414
32415 <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>.
32418 </p>
32419 <p>
32420 We are awaiting an updated paper based on feedback from the San Francisco
32421 review.
32422 </p>
32423
32424
32425
32426
32427
32428 <hr>
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>
32435
32436 <p><b>Addresses JP 31</b></p>
32437
32438 <p>
32439 It is difficult to understand in which case <tt>nested_exception</tt> is applied.
32440 </p>
32441
32442 <p><i>[
32443 Summit:
32444 ]</i></p>
32445
32446  
32447 <blockquote>
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>.
32450 </blockquote>
32451
32452 <p><i>[
32453 2009-10 Santa Cruz:
32454 ]</i></p>
32455
32456
32457 <blockquote>
32458 It doesn't appear that N2619 really addresses this. Alisdair to propose wording.
32459 </blockquote>
32460
32461 <p><i>[
32462 2010 Pittsburgh:
32463 ]</i></p>
32464
32465
32466 <blockquote>
32467 Mark issue 1008 as NAD, the type is adequately described.
32468 </blockquote>
32469
32470
32471
32472 <p><b>Rationale:</b></p>
32473 <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
32478 scenario.
32479 </p>
32480
32481
32482 <p><b>Proposed resolution:</b></p>
32483
32484
32485
32486
32487
32488 <hr>
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>
32494
32495 <p><b>Addresses UK 251</b></p>
32496
32497 <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.
32505 </p>
32506
32507 <p><i>[
32508 2009-07-28 Alisdair adds:
32509 ]</i></p>
32510
32511
32512 <blockquote>
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
32516 appropriate.
32517 </blockquote>
32518
32519 <p><i>[
32520 2009-10 Santa Cruz:
32521 ]</i></p>
32522
32523
32524 <blockquote>
32525 NAD.  Without concepts we do not feel that input iterator post increment
32526 is broken.
32527 </blockquote>
32528
32529
32530
32531 <p><b>Proposed resolution:</b></p>
32532 <p>
32533 Change 24.2.2 [iterator.iterators]:
32534 </p>
32535
32536 <blockquote><pre>concept Iterator&lt;typename X&gt; : Semiregular&lt;X&gt; { 
32537   MoveConstructible reference = typename X::reference; 
32538   <del>MoveConstructible postincrement_result;</del>
32539
32540   <del>requires HasDereference&lt;postincrement_result&gt;;</del>
32541
32542   reference operator*(X&amp;&amp;); 
32543   X&amp; operator++(X&amp;); 
32544   <del>postincrement_result operator++(X&amp;, int);</del>
32545 }
32546 </pre>
32547
32548 <p>...</p>
32549 <pre><del>postincrement_result operator++(X&amp; r, int);</del>
32550 </pre>
32551
32552 <blockquote>
32553 <del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
32554 </blockquote>
32555
32556 </blockquote>
32557
32558 <p>
32559 Change 24.2.3 [input.iterators]:
32560 </p>
32561
32562 <blockquote>
32563 <pre>concept InputIterator&lt;typename X&gt; : Iterator&lt;X&gt;, EqualityComparable&lt;X&gt; { 
32564   ObjectType value_type = typename X::value_type; 
32565   MoveConstructible pointer = typename X::pointer; 
32566
32567   SignedIntegralLike difference_type = typename X::difference_type; 
32568
32569   requires IntegralType&lt;difference_type&gt; 
32570         &amp;&amp; Convertible&lt;reference, const value_type &amp;&gt;; 
32571         &amp;&amp; Convertible&lt;pointer, const value_type*&gt;; 
32572
32573   <del>requires Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</del>
32574
32575   pointer operator-&gt;(const X&amp;); 
32576 }
32577 </pre>
32578 </blockquote>
32579
32580 <p>
32581 Change 24.2.4 [output.iterators]:
32582 </p>
32583
32584 <blockquote>
32585 <pre>auto concept OutputIterator&lt;typename X, typename Value&gt; { 
32586   requires Iterator&lt;X&gt;; 
32587
32588   typename reference = Iterator&lt;X&gt;::reference; 
32589   <del>typename postincrement_result = Iterator&lt;X&gt;::postincrement_result;</del>
32590   requires SameType&lt;reference, Iterator&lt;X&gt;::reference&gt; 
32591         <del>&amp;&amp; SameType&lt;postincrement_result, Iterator&lt;X&gt;::postincrement_result&gt;</del>
32592         <del>&amp;&amp; Convertible&lt;postincrement_result, const X&amp;&gt;</del>
32593         &amp;&amp; HasAssign&lt;reference, Value&gt; 
32594         <del>&amp;&amp; HasAssign&lt;HasDereference&lt;postincrement_result&gt;::result_type, Value&gt;</del>;
32595 }
32596 </pre>
32597 </blockquote>
32598
32599 <p>
32600 Change 24.2.5 [forward.iterators]:
32601 </p>
32602
32603 <p><i>[
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
32605 way.
32606 ]</i></p>
32607
32608
32609 <blockquote>
32610 <pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; { 
32611   <del>requires Convertible&lt;postincrement_result, const X&amp;&gt;;</del>
32612
32613   <ins>MoveConstructible postincrement_result;</ins>
32614   <ins>requires HasDereference&lt;postincrement_result&gt;
32615         &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</ins>
32616
32617   <ins>postincrement_result operator++(X&amp;, int);</ins>
32618
32619   axiom MultiPass(X a, X b) { 
32620     if (a == b) *a == *b; 
32621     if (a == b) ++a == ++b; 
32622   } 
32623 }
32624 </pre>
32625
32626 <blockquote>
32627 <p>-4- ...</p>
32628 </blockquote>
32629
32630 <pre><ins>postincrement_result operator++(X&amp; r, int);</ins>
32631 </pre>
32632
32633 <blockquote>
32634 <p>
32635 <ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
32636 </p>
32637 </blockquote>
32638
32639 </blockquote>
32640
32641
32642
32643
32644
32645
32646 <hr>
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>
32653
32654 <p><b>Addresses UK 263</b></p>
32655
32656 <p>
32657 This requirement on <tt>operator-=</tt> would be better expressed as a default
32658 implementation in the concept, with a matching axiom.
32659 </p>
32660
32661 <p><i>[
32662 Batavia (2009-05):
32663 ]</i></p>
32664
32665 <blockquote>
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.
32671 Move to Open.
32672 </blockquote>
32673
32674
32675 <p><b>Proposed resolution:</b></p>
32676 <p>
32677 Change 24.2.7 [random.access.iterators]:
32678 </p>
32679
32680 <blockquote><pre>concept RandomAccessIterator&lt;typename X&gt; : BidirectionalIterator&lt;X&gt;, LessThanComparable&lt;X&gt; {
32681   ...
32682   X&amp; operator-=(X&amp; <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins>
32683   ...
32684 }
32685 </pre></blockquote>
32686
32687
32688
32689
32690
32691
32692 <hr>
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>
32699
32700 <p><b>Addresses UK 305</b></p>
32701
32702 <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
32705 longer necessary.
32706 </p>
32707
32708 <p><i>[
32709 Batavia (2009-05):
32710 ]</i></p>
32711
32712 <blockquote>
32713 We agree with the proposed resolution.
32714 Move to Tentatively Ready.
32715 </blockquote>
32716
32717 <p><i>[
32718 2009-07 Frankfurt
32719 ]</i></p>
32720
32721
32722 <blockquote>
32723 We believe this is NAD, but this needs to be reviewed against the
32724 post-remove-concepts draft.
32725 </blockquote>
32726
32727
32728
32729 <p><b>Proposed resolution:</b></p>
32730 <p>
32731 Change 25 [algorithms]:
32732 </p>
32733
32734 <blockquote><pre>template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32735   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32736   const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
32737 ...
32738 template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32739   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32740   const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
32741 ...
32742 template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32743   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32744   pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
32745 </pre></blockquote>
32746
32747 <p>
32748 Change 25.4.7 [alg.min.max], p1, p9 and p17:
32749 </p>
32750
32751 <blockquote><pre>template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32752   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32753   const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
32754 ...
32755 template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32756   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32757   const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
32758 ...
32759 template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
32760   <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
32761   pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
32762 </pre></blockquote>
32763
32764
32765
32766
32767
32768
32769 <hr>
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>
32776
32777 <p><b>Addresses UK 199</b></p>
32778
32779 <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.
32787 </p>
32788
32789 <p><i>[
32790 2009-05-09 Alisdair adds:
32791 ]</i></p>
32792
32793
32794 <blockquote>
32795 <p>
32796 The same problem is present in the words added for the
32797 <tt>LvalueReference/RvalueReference</tt> concepts last meeting.
32798 </p>
32799 <p>
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 -&gt; 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
32806 mandated there.
32807 </p>
32808 </blockquote>
32809
32810 <p><i>[
32811 Batavia (2009-05):
32812 ]</i></p>
32813
32814 <blockquote>
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.
32820 </blockquote>
32821
32822
32823 <p><b>Proposed resolution:</b></p>
32824 <p>
32825 Change X [concept.transform] p2:
32826 </p>
32827
32828 <blockquote>
32829 -2- A <del>program</del> <ins>user</ins> shall not provide concept maps for
32830 any concept in 20.1.1.
32831 </blockquote>
32832
32833 <p>
32834 Change  [concept.true] p2:
32835 </p>
32836
32837 <blockquote>
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.
32840 </blockquote>
32841
32842 <p>
32843 Change  [concept.classify] p2:
32844 </p>
32845
32846 <blockquote>
32847 -2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept
32848 maps for any concept in this section.
32849 </blockquote>
32850
32851
32852
32853
32854
32855
32856 <hr>
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>
32863
32864 <p><b>Addresses JP 33</b></p>
32865
32866 <p>
32867 <tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN. 
32868 </p>
32869
32870 <p><b>Original proposed resolution:</b></p>
32871
32872 <p>
32873 Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>.
32874 </p>
32875
32876 <p><i>[
32877 Post Summit, Alisdair adds:
32878 ]</i></p>
32879
32880
32881 <blockquote>
32882 <p>
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
32886 concepts.
32887 </p>
32888 <p>
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>.
32890 </p>
32891 </blockquote>
32892
32893
32894
32895 <p><b>Proposed resolution:</b></p>
32896 <p>
32897 Recommend NAD.
32898 </p>
32899
32900
32901
32902
32903
32904 <hr>
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>
32910
32911 <p><b>Addresses US 66</b></p>
32912
32913 <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). 
32916 </p>
32917
32918 <p><b>Original proposed resolution:</b></p>
32919
32920 <p>
32921 State that the <tt>Regular</tt> concept does not apply to floating-point types. 
32922 </p>
32923
32924 <p><i>[
32925 Summit:
32926 ]</i></p>
32927
32928
32929 <blockquote>
32930 <p>
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>.
32932 </p>
32933 </blockquote>
32934
32935 <p><i>[
32936 Post Summit, Alisdair adds:
32937 ]</i></p>
32938
32939
32940 <blockquote>
32941 <p>
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
32943 feature.
32944 </p>
32945 </blockquote>
32946
32947
32948
32949 <p><b>Proposed resolution:</b></p>
32950
32951
32952
32953
32954
32955 <hr>
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>
32962
32963 <p><b>Addresses US 70</b></p>
32964
32965 <p>
32966 Specifications now expressed via narrative text are more accurately and
32967 clearly expressed via executable code.
32968 </p>
32969 <p>
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.
32975 </p>
32976
32977 <p><i>[
32978 Summit:
32979 ]</i></p>
32980
32981
32982 <blockquote>
32983 <p>
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.
32987 </p>
32988 </blockquote>
32989
32990
32991
32992 <p><b>Proposed resolution:</b></p>
32993
32994
32995
32996
32997
32998 <hr>
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>
33005
33006 <p><b>Addresses UK 204</b></p>
33007
33008 <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. 
33011 </p>
33012
33013 <p><b>Original proposed resolutuion:</b></p>
33014
33015 <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>. 
33017 </p>
33018
33019 <p><i>[
33020 Summit:
33021 ]</i></p>
33022
33023
33024 <blockquote>
33025 Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
33026 </blockquote>
33027
33028 <p><i>[
33029 Post Summit, Alisdair adds:
33030 ]</i></p>
33031
33032
33033 <blockquote>
33034 paper
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.
33038 </blockquote>
33039
33040 <p><i>[
33041 2009-10 Santa Cruz:
33042 ]</i></p>
33043
33044
33045 <blockquote>
33046 Mark NAD as suggested.
33047 </blockquote>
33048
33049
33050
33051 <p><b>Proposed resolution:</b></p>
33052
33053
33054
33055
33056
33057 <hr>
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>
33064
33065 <p><b>Addresses UK 212</b></p>
33066
33067 <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.
33072 </p>
33073
33074 <p><i>[
33075 Summit:
33076 ]</i></p>
33077
33078
33079 <blockquote>
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>&lt;memory&gt;</tt>.
33083 </blockquote>
33084
33085
33086
33087 <p><b>Proposed resolution:</b></p>
33088
33089
33090
33091
33092
33093 <hr>
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>
33100
33101 <p><b>Addresses DE 22</b></p>
33102
33103 <p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</p>
33104
33105 <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&lt;T1&gt;</tt>, because it (arguably)
33109 "contains" <tt>T1</tt>.
33110 </p>
33111
33112 <p><i>[
33113 Summit:
33114 ]</i></p>
33115
33116
33117 <blockquote>
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>.
33121 </blockquote>
33122
33123 <p><i>[
33124 2009-05-09 Alisdair adds:
33125 ]</i></p>
33126
33127
33128 <blockquote>
33129 Phrasing should be "publicly and
33130 unambiguously derived from" and probably back in reference_wrapper too.  Updated
33131 wording supplied.
33132 </blockquote>
33133
33134 <p><i>[
33135 Batavia (2009-05):
33136 ]</i></p>
33137
33138 <blockquote>
33139 We agree with the proposed wording.
33140 Move to NAD Editorial.
33141 </blockquote>
33142
33143
33144 <p><b>Proposed resolution:</b></p>
33145 <p>
33146 (no changes to <tt>&lt;functional&gt;</tt> synopsis required)
33147 </p>
33148
33149 <p>
33150 Change synopsis in Class template function 20.8.14.2 [func.wrap.func]:
33151 </p>
33152
33153 <blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
33154 class function&lt;R(ArgTypes...)&gt; 
33155   : public unary_function&lt;T1, R&gt;      // <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&lt;T1, T2, R&gt; // <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>
33159 {
33160    ...
33161 </pre></blockquote>
33162
33163 <p>
33164 Add new p1/p2 before 20.8.14.2.1 [func.wrap.func.con]:
33165 </p>
33166
33167 <blockquote>
33168 <p><ins>
33169 The template instantiation <tt>function&lt;R(T1)&gt;</tt> shall be publicly and
33170 unambiguously derived from 
33171 <tt>std::unary_function&lt;T1,R&gt;</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>.
33173 </ins></p>
33174
33175 <p><ins>
33176 The template instantiation <tt>function&lt;R(T1,T2)&gt;</tt> shall be publicly and
33177 unambiguously derived from 
33178 <tt>std::binary_function&lt;T1,T2,R&gt;</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>.
33181 </ins></p>
33182
33183 <pre>explicit function();
33184 </pre>
33185 </blockquote>
33186
33187
33188
33189
33190
33191
33192 <hr>
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>
33199
33200 <p><b>Addresses JP 39</b></p>
33201
33202 <p>
33203 There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>.
33204 </p>
33205
33206 <p><i>[
33207 2009-05-01 Daniel adds:
33208 ]</i></p>
33209
33210
33211 <blockquote>
33212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a> removes the second constructor.
33213 </blockquote>
33214
33215 <p><i>[
33216 Batavia (2009-05):
33217 ]</i></p>
33218
33219 <blockquote>
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.
33225 </blockquote>
33226
33227 <p><i>[
33228 2009-07 Frankfurt:
33229 ]</i></p>
33230
33231
33232 <blockquote>
33233 Constructors have no definition.
33234 </blockquote>
33235
33236
33237
33238 <p><b>Proposed resolution:</b></p>
33239 <p>
33240 Correct as follows in 20.8.14.2 [func.wrap.func] (class definition)
33241 </p>
33242
33243 <blockquote><pre> template&lt;class F, Allocator Alloc&gt;
33244    <ins>requires ConstructibleWithAllocator&lt;F, Alloc&gt;
33245      &amp;&amp; call=Callable&lt;F, ArgTypes...&gt;
33246      &amp;&amp; Convertible&lt;call::result_type, R&gt;</ins>
33247    function(allocator_arg_t, const Alloc&amp;, F);
33248  template&lt;class F, Allocator Alloc&gt;
33249    <ins>requires ConstructibleWithAllocator&lt;F,Alloc&gt;
33250      &amp;&amp; call=Callable&lt;F, ArgTypes...&gt;
33251      &amp;&amp; Convertible&lt;call::result_type, R&gt;</ins>
33252    function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);
33253 </pre></blockquote>
33254
33255
33256
33257
33258
33259
33260 <hr>
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>
33267
33268 <p><b>Addresses UK 208</b></p>
33269
33270 <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.
33274 </p>
33275
33276
33277
33278 <p><b>Proposed resolution:</b></p>
33279
33280
33281
33282
33283
33284 <hr>
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>
33291
33292 <p><b>Addresses UK 209</b></p>
33293
33294 <p>
33295 Smart pointers cannot be used in constrained templates.
33296 </p>
33297
33298 <p><i>[
33299 Summit:
33300 ]</i></p>
33301
33302
33303 <blockquote>
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.
33306 </blockquote>
33307
33308 <p><i>[
33309 Peter Dimov adds:
33310 ]</i></p>
33311
33312
33313 <blockquote>
33314 <tt>shared_ptr&lt;T&gt;</tt> and <tt>weak_ptr&lt;T&gt;</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>.
33319 </blockquote>
33320
33321
33322
33323 <p><b>Proposed resolution:</b></p>
33324
33325
33326
33327
33328
33329 <hr>
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>
33335
33336 <p><b>Addresses UK 213</b></p>
33337
33338 <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. 
33346 </p>
33347
33348 <p>
33349 Suggested direction:
33350 </p>
33351 <p>
33352 The primary allocator template should be constrained to require
33353 <tt>ObjectType&lt;T&gt;</tt> and <tt>FreeStoreAllocatable&lt;T&gt;</tt>.
33354 Further operations to be constrained as required.
33355 </p>
33356
33357 <p><i>[
33358 Summit:
33359 ]</i></p>
33360
33361
33362 <blockquote>
33363 Agree as stated. A future paper will address additional related issues.
33364 </blockquote>
33365
33366
33367
33368 <p><b>Proposed resolution:</b></p>
33369
33370
33371
33372
33373
33374 <hr>
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>
33380
33381 <p><b>Addresses UK 214</b></p>
33382
33383 <p>
33384 <tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely
33385 used in constrained templates 
33386 </p>
33387
33388 <p><i>[
33389 Summit:
33390 ]</i></p>
33391
33392
33393 <blockquote>
33394 We look forward to a paper on this topic. We recommend no action until a
33395 paper is available.
33396 </blockquote>
33397
33398 <p><i>[
33399 Post Summit Alisdair provided wording and rationale.
33400 ]</i></p>
33401
33402
33403
33404
33405 <p><b>Proposed resolution:</b></p>
33406 <p>
33407 20.9 [memory] p2
33408 </p>
33409 <p>
33410 Update the synopsis for <tt>&lt;memory&gt;</tt>
33411 </p>
33412 <blockquote><pre>// 20.7.8, raw storage iterator:
33413 template &lt;<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T&gt; 
33414   <ins>requires OutputIterator&lt; OutIter, T &gt;</ins>
33415     class raw_storage_iterator;
33416
33417 <ins>template &lt;ForwardIterator OutIter, ObjectType T&gt; 
33418   requires OutputIterator&lt; OutIter, T &gt;
33419   concept_map Iterator&lt;raw_storage_iterator&lt; OutIter, T &gt; &gt; { }</ins>
33420 </pre></blockquote>
33421
33422
33423 <p>
33424 20.9.6 [storage.iterator] p1
33425 </p>
33426 <p>
33427 Replace class template definition with:
33428 </p>
33429 <blockquote><pre>namespace std { 
33430   template &lt;<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T&gt; 
33431     <ins>requires OutputIterator&lt; OutIter, T &gt;</ins>
33432   class raw_storage_iterator 
33433     : public iterator&lt;output_iterator_tag,void,void,void,void&gt; { 
33434   public: 
33435     explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x); 
33436
33437     raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator*(); 
33438     raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator=(const T&amp; element); 
33439     raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator++(); 
33440     raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del> operator++(int); 
33441   }; 
33442
33443   <ins>template &lt;ForwardIterator OutIter, ObjectType T&gt; 
33444     requires OutputIterator&lt; OutIter, T &gt;
33445     concept_map Iterator&lt;raw_storage_iterator&lt; OutIter, T &gt; &gt; { }</ins>
33446 }
33447 </pre></blockquote>
33448
33449
33450 <p><b>Rationale:</b></p>
33451 <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:
33454 </p>
33455
33456 <ol type="i">
33457 <li>
33458 The initial iterator passed by value is expected to remain valid,
33459 pointing to the initialized region of memory.
33460 </li>
33461 <li>
33462 to avoid breaking the declaration of post-increment operator which would
33463 require some kind of proxy formulation to support generalised InputIterators.
33464 </li>
33465 </ol>
33466
33467
33468
33469
33470
33471
33472 <hr>
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>
33479
33480 <p><b>Addresses UK 210</b></p>
33481
33482 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a></p>
33483
33484 <p>
33485 Specialized algorithms for memory managenment need requirements to be
33486 easily usable in constrained templates.
33487 </p>
33488
33489 <p><i>[
33490 Summit:
33491 ]</i></p>
33492
33493
33494 <blockquote>
33495 We look forward to a paper on this topic. We recommend no action until a
33496 paper is available.
33497 </blockquote>
33498
33499 <p><i>[
33500 Post Summit Alisdair provided wording.
33501 ]</i></p>
33502
33503
33504 <p><i>[
33505 Post Summit:
33506 ]</i></p>
33507
33508
33509 <blockquote>
33510 <p>
33511 Daniel adds:
33512 </p>
33513
33514 <blockquote>
33515 <ol>
33516 <li>
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>.
33520 </li>
33521 <li>
33522 <p>
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:
33526 </p>
33527 <ol type="a">
33528 <li>
33529 for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n &gt; Size(0); ++result, ++first, --n) {</tt>
33530 </li>
33531 <li>
33532 for <tt>uninitialized_fill_n</tt>: <tt>for (; n &gt; Size(0); ++first, --n) {</tt>
33533 </li>
33534 </ol>
33535 </li>
33536 </ol>
33537 </blockquote>
33538
33539 <p>
33540 Alisdair adds:
33541 </p>
33542 <blockquote>
33543 For the record I agree with Daniel's suggestion.
33544 </blockquote>
33545
33546 </blockquote>
33547
33548
33549
33550 <p><b>Proposed resolution:</b></p>
33551 <p>
33552 20.9 [memory] p2
33553 </p>
33554 <p>
33555 Update the synopsis for <tt>&lt;memory&gt;</tt>
33556 </p>
33557 <blockquote><pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
33558          <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
33559    <ins>requires ForwardIterator&lt;OutIter&gt;</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);
33563
33564 template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
33565           <del>class</del> <ins>IntegralLike</ins> Size,
33566           <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
33567   <ins>requires ForwardIterator&lt;OutIter&gt;</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);
33571
33572 template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T&gt;
33573   <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
33574   void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 
33575                           const T&amp; x);
33576
33577 template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T&gt; 
33578   <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
33579   void
33580   uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T&amp; x);
33581 </pre></blockquote>
33582
33583 <p>
33584 Update as follows:
33585 </p>
33586
33587 <p>
33588 uninitialized_copy 20.9.8.2 [uninitialized.copy]
33589 </p>
33590
33591 <blockquote><pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
33592          <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
33593    <ins>requires ForwardIterator&lt;OutIter&gt;</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);
33597 </pre>
33598
33599 <blockquote>
33600 <p>
33601 -1- <i>Effects:</i>
33602 </p>
33603 <blockquote><pre>for (; first != last; ++result, ++first)  {
33604    new (static_cast&lt;void*&gt;(&amp;*result))
33605        <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>OutIter</ins>::value_type(*first);
33606 }
33607 </pre></blockquote>
33608
33609 <p>
33610 -2- <i>Returns:</i> <tt>result</tt>
33611 </p>
33612
33613 </blockquote>
33614
33615 <pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
33616           <del>class</del> <ins>IntegralLike</ins> Size,
33617           <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
33618   <ins>requires ForwardIterator&lt;OutIter&gt;</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);
33622 </pre>
33623
33624 <blockquote>
33625 <p>
33626 -3- Effects:
33627 </p>
33628 <blockquote><pre>for ( ; n &gt; <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) {
33629    new (static_cast&lt;void*&gt;(&amp;*result))
33630        <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>OutIter</ins>::value_type(*first);
33631 }
33632 </pre></blockquote>
33633 <p>
33634 -4- <i>Returns:</i> result
33635 </p>
33636 </blockquote>
33637
33638 </blockquote>
33639
33640
33641 <p>
33642 uninitialized_fill 20.9.8.3 [uninitialized.fill]
33643 </p>
33644
33645 <blockquote><pre>template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T&gt;
33646   <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
33647   void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 
33648                           const T&amp; x);
33649 </pre>
33650
33651 <blockquote>
33652 <p>
33653 -1- <i>Effects:</i>
33654 </p>
33655 <blockquote><pre>for (; first != last; ++first) {
33656    new ( static_cast&lt;void*&gt;( &amp;*first) ) 
33657        <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>Iter</ins>::value_type(x);
33658 }
33659 </pre></blockquote>
33660 </blockquote>
33661 </blockquote>
33662
33663
33664 <p>
33665 uninitialized_fill_n 20.9.8.4 [uninitialized.fill.n]
33666 </p>
33667
33668 <blockquote><pre>template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T&gt; 
33669   <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
33670   void
33671   uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T&amp; x);
33672 </pre>
33673
33674 <blockquote>
33675 <p>
33676 -1- <i>Effects:</i>
33677 </p>
33678 <blockquote><pre>for (; n<del>--</del> <ins>&gt; Size(0)</ins>; ++first<ins>, --n</ins>) {
33679    new ( static_cast&lt;void*&gt;( &amp;*first) ) 
33680        <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>Iter</ins>::value_type(x);
33681 }
33682 </pre></blockquote>
33683 </blockquote>
33684 </blockquote>
33685
33686
33687
33688
33689
33690
33691 <hr>
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>
33698
33699 <p><b>Addresses US 78</b></p>
33700
33701 <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. 
33704 </p>
33705
33706 <p><i>[
33707 Summit:
33708 ]</i></p>
33709
33710
33711 <blockquote>
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.
33715 </blockquote>
33716
33717 <p><i>[
33718 Peter Dimov adds:
33719 ]</i></p>
33720
33721
33722 <blockquote>
33723 This is basically a request for <tt>shared_ptr&lt;&gt;::release</tt> in
33724 disguise, with all the associated problems. Not a good idea.
33725 </blockquote>
33726
33727 <p><i>[
33728 2009-07 post-Frankfurt:
33729 ]</i></p>
33730
33731
33732 <blockquote>
33733 <p>
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>
33736 </p>
33737 <p>
33738 The implementation of such a member is non-trivial (and maybe
33739 impossible), because it would need to account for the deleter.
33740 </p>
33741 </blockquote>
33742
33743 <p><i>[
33744 2009-07-26 Howard sets to Tentatively NAD Future.
33745 ]</i></p>
33746
33747
33748 <blockquote>
33749 <p>
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.
33753 </p>
33754
33755 <p>
33756 However such an extension would need to solve a couple of problems:
33757 </p>
33758
33759 <ol>
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?
33763 </li>
33764
33765 <li>
33766 <p>
33767 How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
33768 </p>
33769 <p>
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.
33774 </p>
33775 <p>
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.
33778 </p>
33779 <p>
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
33783 the constructor.
33784 </p>
33785 </li>
33786 </ol>
33787
33788 <p>
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.
33791 </p>
33792 </blockquote>
33793
33794 <p><i>[
33795 2009 Santa Cruz:
33796 ]</i></p>
33797
33798
33799 <blockquote>
33800 Moved to NAD Future.
33801 </blockquote>
33802
33803
33804
33805 <p><b>Proposed resolution:</b></p>
33806
33807
33808
33809
33810
33811 <hr>
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>
33818
33819 <p><b>Addresses JP 45</b></p>
33820
33821 <p>
33822 <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>
33823 don't correspond to concept.
33824 </p>
33825 <blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt; class duration; 
33826 template &lt;class Clock, class Duration = typename Clock::duration&gt; class time_point; 
33827 </pre></blockquote>
33828 <p>
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]. 
33832 </p>
33833
33834 <p><i>[
33835 Summit:
33836 ]</i></p>
33837
33838
33839 <blockquote>
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.
33842 </blockquote>
33843
33844
33845
33846 <p><b>Proposed resolution:</b></p>
33847
33848
33849
33850
33851
33852 <hr>
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>
33860
33861 <p><b>Addresses UK 226</b></p>
33862
33863 <p>
33864 <tt>&lt;array&gt;</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.
33869 </p>
33870 <p>
33871 If <tt>&lt;array&gt;</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.
33874 </p>
33875
33876 <p><i>[
33877 Summit:
33878 ]</i></p>
33879
33880
33881 <blockquote>
33882 Agree. The proposed resolution is incomplete. Further work required.
33883 </blockquote>
33884
33885 <p><i>[
33886 2009-05-01 Daniel adds:
33887 ]</i></p>
33888
33889
33890 <blockquote>
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.
33893 </blockquote>
33894
33895 <p><i>[
33896 2009-07 post-Frankfurt:
33897 ]</i></p>
33898
33899
33900 <blockquote>
33901 Howard is to draft a note that explains what happens to references.
33902 </blockquote>
33903
33904 <p><i>[
33905 2009-10 Santa Cruz:
33906 ]</i></p>
33907
33908
33909 <blockquote>
33910 Mark as NAD.  No consensus for change.
33911 </blockquote>
33912
33913
33914
33915 <p><i>[
33916 2009-08-01 Howard provided wording.
33917 ]</i></p>
33918
33919
33920 <p><b>Proposed resolution:</b></p>
33921 <p>
33922 Add a paragraph to 23.3.1.2 [array.special]:
33923 </p>
33924
33925 <blockquote><pre>template &lt;Swappable T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x, array&lt;T,N&gt;&amp; y);
33926 </pre>
33927 <blockquote>
33928 <p>
33929 <i>Effects:</i>
33930 </p>
33931 <blockquote><pre>swap_ranges(x.begin(), x.end(), y.begin());
33932 </pre></blockquote>
33933
33934 <p><ins>
33935 [<i>Note:</i>
33936 Outstanding iterators, references and pointers may be invalidated.
33937 \97 <i>end note</i>]
33938 </ins></p>
33939 </blockquote>
33940 </blockquote>
33941
33942
33943
33944
33945
33946 <hr>
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>
33953
33954 <p><b>Addresses UK 231</b></p>
33955
33956 <p>
33957 p9-p11 are redundant now that Concepts define what it means to be an
33958 Iterator and guide overload resolution accordingly. 
33959 </p>
33960
33961 <p><i>[
33962 Summit:
33963 ]</i></p>
33964
33965
33966 <blockquote>
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.
33970 </blockquote>
33971
33972
33973
33974 <p><b>Proposed resolution:</b></p>
33975 <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. 
33979 </p>
33980
33981
33982
33983
33984
33985 <hr>
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>
33993
33994 <p><b>Addresses UK 239</b></p>
33995
33996 <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.
34000 </p>
34001
34002 <p>
34003 Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
34004 </p>
34005 <p>
34006 <tt>a.extract(q)&gt;</tt>, Return type <tt>pair&lt;key, iterator&gt;</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>.
34012 </p>
34013
34014 <p><i>[
34015 Summit:
34016 ]</i></p>
34017
34018
34019 <blockquote>
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.
34022 </blockquote>
34023
34024 <p><i>[
34025 Post Summit Alisdair adds:
34026 ]</i></p>
34027
34028
34029 <blockquote>
34030 Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
34031 </blockquote>
34032
34033 <p><i>[
34034 2009-07 post-Frankfurt:
34035 ]</i></p>
34036
34037
34038 <blockquote>
34039 Leave Open. Alisdair to contact Chris Jefferson about this.
34040 </blockquote>
34041
34042 <p><i>[
34043 2009-09-20 Howard adds:
34044 ]</i></p>
34045
34046
34047 <blockquote>
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.
34051 </blockquote>
34052
34053 <p><i>[
34054 2009-10 Santa Cruz:
34055 ]</i></p>
34056
34057
34058 <blockquote>
34059 Mark as NAD Future. No consensus to make the change at this time.
34060 </blockquote>
34061
34062
34063
34064 <p><b>Proposed resolution:</b></p>
34065 <p>
34066 In 23.2.4 [associative.reqmts] Table 85, add:
34067 </p>
34068
34069 <blockquote>
34070 <table border="1">
34071 <caption>Table 85 --  Associative container requirements (in addition to container)</caption>
34072 <tbody><tr>
34073 <th>Expression</th>
34074 <th>Return type</th>
34075 <th>Assertion/note<br>pre-/post-condition</th>
34076 <th>Complexity</th>
34077 </tr>
34078 <tr><td><tt>a.erase(q)</tt></td>
34079 <td>...</td>
34080 <td>...</td>
34081 <td>...</td>
34082 </tr><tr>
34083 <td><ins><tt>a.extract(q)</tt></ins></td>
34084 <td><ins><tt>pair&lt;key_type, iterator&gt;</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>
34091 </tr>
34092 </tbody></table>
34093 </blockquote>
34094
34095 <p>
34096 In 23.2.5 [unord.req] Table 87, add:
34097 </p>
34098
34099 <blockquote>
34100 <table border="1">
34101 <caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
34102 <tbody><tr>
34103 <th>Expression</th>
34104 <th>Return type</th>
34105 <th>Assertion/note<br>pre-/post-condition</th>
34106 <th>Complexity</th>
34107 </tr>
34108 <tr><td><tt>a.erase(q)</tt></td>
34109 <td>...</td>
34110 <td>...</td>
34111 <td>...</td>
34112 </tr><tr>
34113 <td><ins><tt>a.extract(q)</tt></ins></td>
34114 <td><ins><tt>pair&lt;key_type, iterator&gt;</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>
34121 </tr>
34122 </tbody></table>
34123 </blockquote>
34124
34125
34126
34127
34128
34129 <hr>
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>
34136
34137 <p><b>Addresses UK 244</b></p>
34138
34139 <p>
34140 The validity of the expression <tt>&amp;a[n] == &amp;a[0] + n</tt> is contingent on
34141 <tt>operator&amp;</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).
34146 </p>
34147
34148 <p>
34149 Suggested solution:
34150 </p>
34151
34152 <p>
34153 Define a <tt>ContiguousStrorage</tt> and apply it to
34154 <tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
34155 </p>
34156
34157 <p><i>[
34158 Summit:
34159 ]</i></p>
34160
34161
34162 <blockquote>
34163 Agree with the issue but not the details of the proposed solution. Walter to
34164 provide wording for the new concept.
34165 </blockquote>
34166
34167 <p><i>[
34168 Post Summit Alisdair adds:
34169 ]</i></p>
34170
34171
34172 <blockquote>
34173 Another LWG subgroup wondered if this concept
34174 should extend to <tt>complex&lt;T&gt;</tt>, and so not be built on the container concept at
34175 all?
34176 </blockquote>
34177
34178 <p><i>[
34179 2009-07 post-Frankfurt:
34180 ]</i></p>
34181
34182
34183 <blockquote>
34184 Leave Open, pending a post-Concepts Working Draft.
34185 </blockquote>
34186
34187 <p><i>[
34188 2009-10 Santa Cruz:
34189 ]</i></p>
34190
34191
34192 <blockquote>
34193 Mark issue 1042 as NAD, in rationale state that this was solved by removal of concepts.
34194 </blockquote>
34195
34196
34197
34198 <p><b>Proposed resolution:</b></p>
34199 <p>
34200 Add to <tt>&lt;container_concepts&gt;</tt> synopsis in  [container.concepts]
34201 </p>
34202
34203 <blockquote><pre><ins>concept&lt; typename C &gt; ContiguousStorageContainer <i>see below</i>;</ins>
34204 </pre></blockquote>
34205
34206 <p>
34207 Add a new section to the end of  [container.concepts]
34208 </p>
34209
34210 <blockquote>
34211 <p>
34212 23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
34213 </p>
34214
34215 <pre>concept ContiguousStorageContainer&lt; typename C &gt;
34216   : Container&lt;C&gt;
34217 {
34218   value_type* data(C&amp;);
34219
34220   axiom Contiguity(C&amp; c, size_type i) {
34221     if( i &lt; size(c) ) {
34222          addressof( * (data(c) + i) )
34223       == addressof( * advance(data(c), i) );
34224     }
34225   }
34226 }
34227 </pre>
34228
34229 <p>
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.
34235 </p>
34236
34237 <pre>value_type * data( C&amp; );
34238 </pre>
34239
34240 <blockquote>
34241 <i>Returns:</i> a pointer to the first element in the region of storage.
34242 Result is unspecified for an empty container.
34243 </blockquote>
34244
34245 </blockquote>
34246
34247 <p>
34248 Change 23.3.1 [array] p1:
34249 </p>
34250
34251 <blockquote>
34252 -1- The header <tt>&lt;array&gt;</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&lt;T, N&gt;</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&lt;T, N&gt;</tt> <del>then it obeys the identity <tt>&amp;a[n]
34259 == &amp;a[0] + n</tt> for all <tt>0 &lt;= n &lt; N</tt></del>
34260 <ins>satisfies the concept <tt>ContiguousStorageContainer&lt; array&lt;T,
34261 N&gt;&gt;</tt></ins>.
34262 </blockquote>
34263
34264 <p>
34265 Add to the synopsis in 23.3.1 [array]:
34266 </p>
34267
34268 <blockquote><pre>    ...
34269     T * data(); 
34270     const T * data() const; 
34271   };
34272
34273   <ins>template&lt; typename T, size_t N &gt;</ins>
34274     <ins>concept_map ContiguousStorageContainer&lt; array&lt;T, N&gt;&gt; {};</ins>
34275
34276 </pre></blockquote>
34277
34278 <p>
34279 Change 23.4.1 [vector] p1:
34280 </p>
34281
34282 <blockquote>
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&lt;T, Alloc&gt;</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>&amp;v[n] == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt;
34292 v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer&lt;
34293 vector&lt; T, Alloc&gt;&gt;</tt></ins>.
34294 </blockquote>
34295
34296 <p>
34297 Add at the end of the synopsis in 23.4.1 [vector] p2:
34298 </p>
34299
34300 <blockquote><pre><ins>template&lt; typename T, typename A &gt;
34301   requires !SameType&lt; T, bool &gt;
34302   concept_map ContiguousStorageContainer&lt; vector&lt;T, A&gt;&gt; {};</ins>
34303 </pre></blockquote>
34304
34305
34306
34307 <p><b>Rationale:</b></p>
34308 Solved by removal of concepts.
34309
34310
34311
34312
34313
34314 <hr>
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>
34322
34323 <p><b>Addresses US 91</b></p>
34324
34325 <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]).
34328 </p>
34329
34330 <p>
34331 Suggested solution:
34332 </p>
34333
34334 <p>
34335 Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
34336 </p>
34337
34338 <p><i>[
34339 Anthony Williams adds:
34340 ]</i></p>
34341
34342
34343 <blockquote>
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.
34349 </blockquote>
34350
34351
34352 <p><i>[
34353 Summit:
34354 ]</i></p>
34355
34356
34357 <blockquote>
34358 Group agrees with the resolution as proposed by Anthony Williams in the attached note.
34359 </blockquote>
34360
34361 <p><i>[
34362 Batavia (2009-05):
34363 ]</i></p>
34364
34365 <blockquote>
34366 We recommend the proposed resolution be reviewed
34367 by members of the Concurrency Subgroup.
34368 </blockquote>
34369
34370 <p><i>[
34371 2009-07 post-Frankfurt:
34372 ]</i></p>
34373
34374
34375 <blockquote>
34376 This is likely to be addressed by Lawrence's upcoming paper. He will
34377 adopt the proposed resolution.
34378 </blockquote>
34379
34380 <p><i>[
34381 2009-08-17 Handled by
34382 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
34383 ]</i></p>
34384
34385
34386 <p><i>[
34387 2009-10 Santa Cruz:
34388 ]</i></p>
34389
34390
34391 <blockquote>
34392 NAD Editorial.  Solved by
34393 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
34394 </blockquote>
34395
34396
34397
34398 <p><b>Proposed resolution:</b></p>
34399 <p>
34400 Change 29.6 [atomics.types.operations] p18:
34401 </p>
34402
34403 <blockquote>
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>
34423 </blockquote>
34424
34425
34426
34427
34428
34429
34430 <hr>
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>
34437
34438 <p><b>Addresses UK 329</b></p>
34439
34440 <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.
34445 </p>
34446
34447 <p>
34448 Simple Proposal:
34449 </p>
34450
34451 <p>
34452 Provide a simple function along the lines of: 
34453 </p>
34454 <blockquote><pre>template&lt; typename F, typename ... Args &gt;
34455   requires Callable&lt; F, Args... &gt;
34456     future&lt; Callable::result_type &gt; async( F&amp;&amp; f, Args &amp;&amp; ... ); 
34457 </pre></blockquote>
34458
34459 <p>
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&lt;Args&gt;(args...)</tt>
34462 but details are left unspecified to allow different scheduling and thread
34463 spawning implementations. 
34464 </p>
34465 <p>
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. 
34469 </p>
34470 <p>
34471 The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls. 
34472 </p>
34473 <p>
34474 No two incomplete async tasks shall see the same value of
34475 <tt>this_thread::get_id()</tt>. 
34476 </p>
34477 <p>
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>] 
34482 </p>
34483
34484 <p><i>[
34485 Summit:
34486 ]</i></p>
34487
34488
34489 <blockquote>
34490 <p>
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.
34499 </p>
34500 <p>
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.
34505 </p>
34506 </blockquote>
34507
34508 <p><i>[
34509 2009-10 Santa Cruz:
34510 ]</i></p>
34511
34512
34513 <blockquote>
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.
34517 </blockquote>
34518
34519
34520
34521 <p><b>Proposed resolution:</b></p>
34522
34523
34524
34525
34526
34527 <hr>
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>
34534
34535 <p><b>Addresses UK 334</b></p>
34536
34537 <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.
34541 </p>
34542
34543 <p><i>[
34544 Summit:
34545 ]</i></p>
34546
34547
34548 <blockquote>
34549 <p>
34550 Agree, move to Review.
34551 </p>
34552 </blockquote>
34553
34554 <p><i>[
34555 2009-04-03 Thomas J. Gritzan adds:
34556 ]</i></p>
34557
34558
34559 <blockquote>
34560 <p>
34561 This issue also applies to <tt>shared_future::get()</tt>.
34562 </p>
34563
34564 <p>
34565 Suggested wording:
34566 </p>
34567
34568 <p>
34569 Add a paragraph to 30.6.7 [futures.shared_future]:
34570 </p>
34571
34572 <blockquote><pre>void shared_future&lt;void&gt;::get() const;
34573 </pre>
34574 <blockquote>
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>.
34577 </blockquote>
34578 </blockquote>
34579 </blockquote>
34580
34581 <p><i>[
34582 Batavia (2009-05):
34583 ]</i></p>
34584
34585 <blockquote>
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.
34590 </blockquote>
34591
34592 <p><i>[
34593 2009-10 Santa Cruz:
34594 ]</i></p>
34595
34596
34597 <blockquote>
34598 NAD Editorial.  Solved by
34599 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34600 </blockquote>
34601
34602
34603
34604 <p><b>Proposed resolution:</b></p>
34605 <p>
34606 Add a paragraph to 30.6.6 [futures.unique_future]:
34607 </p>
34608
34609 <blockquote><pre>R&amp;&amp; unique_future::get(); 
34610 R&amp; unique_future&lt;R&amp;&gt;::get(); 
34611 void unique_future&lt;void&gt;::get();
34612 </pre>
34613 <blockquote>
34614 <p><i>Note:</i>...</p>
34615 <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>
34618 </p>
34619 <p>
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.
34624 </p>
34625 </blockquote>
34626 </blockquote>
34627
34628
34629
34630
34631
34632 <hr>
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>
34639
34640 <p><b>Addresses UK 335</b></p>
34641
34642 <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.
34647 </p>
34648
34649 <blockquote><pre>std::promise&lt;int&gt; p;
34650 std::unique_future&lt;int&gt; uf(p.get_future());
34651 std::unique_future&lt;int&gt; uf2(std::move(uf));
34652 uf.wait(); <font color="#C80000">// oops, uf has no result to wait for. </font>
34653 </pre></blockquote>
34654
34655 <p>
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).
34660 </p>
34661
34662 <p>
34663 Then we can say:
34664 </p>
34665
34666 <blockquote><pre>if(uf.waitable()) uf.wait();
34667 </pre></blockquote>
34668
34669 <p><i>[
34670 Summit:
34671 ]</i></p>
34672
34673
34674 <blockquote>
34675 <p>
34676 Create an issue. Requires input from Howard. Probably NAD.
34677 </p>
34678 </blockquote>
34679
34680 <p><i>[
34681 Post Summit, Howard thows in his two cents:
34682 ]</i></p>
34683
34684
34685 <blockquote>
34686 <p>
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>:
34689 </p>
34690
34691 <blockquote><pre>template &lt;class R&gt;
34692 class future
34693 {
34694 public:
34695     typedef R result_type;
34696 private:
34697     future(const future&amp;);// = delete;
34698     future&amp; operator=(const future&amp;);// = delete;
34699
34700     template &lt;class R1, class F1&gt; friend class prommise;
34701 public:
34702     future();
34703     ~future();
34704
34705     future(future&amp;&amp; f);
34706     future&amp; operator=(future&amp;&amp; f);
34707
34708     void swap(future&amp;&amp; f);
34709
34710     <b>bool joinable() const;</b>
34711     bool is_normal() const;
34712     bool is_exceptional() const;
34713     bool is_ready() const;
34714
34715     R get();
34716
34717     void join();
34718     template &lt;class ElapsedTime&gt;
34719         bool timed_join(const ElapsedTime&amp;);
34720 };
34721 </pre></blockquote>
34722
34723 <p>
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.
34727 </p>
34728 </blockquote>
34729
34730 <p><i>[
34731 2009-10 Santa Cruz:
34732 ]</i></p>
34733
34734
34735 <blockquote>
34736 NAD Editorial.  Solved by
34737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34738 </blockquote>
34739
34740
34741
34742 <p><b>Proposed resolution:</b></p>
34743
34744
34745
34746
34747
34748 <hr>
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>
34756
34757 <p><b>Addresses UK 339</b></p>
34758
34759 <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>.
34763 </p>
34764
34765 <p><i>[
34766 Summit:
34767 ]</i></p>
34768
34769
34770 <blockquote>
34771 <p>
34772 Agree, move to Review.
34773 </p>
34774 </blockquote>
34775
34776 <p><i>[
34777 Batavia (2009-05):
34778 ]</i></p>
34779
34780 <blockquote>
34781 We recommend deferring this issue until after Detlef's paper (on futures)
34782 has been issued.
34783 </blockquote>
34784
34785 <p><i>[
34786 2009-10 Santa Cruz:
34787 ]</i></p>
34788
34789
34790 <blockquote>
34791 NAD Editorial.  Solved by
34792 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34793 </blockquote>
34794
34795
34796
34797 <p><b>Proposed resolution:</b></p>
34798 <p>
34799 Strike 30.6.5 [futures.promise] p6 and change p7:
34800 </p>
34801
34802 <blockquote><pre>promise&amp; operator=(promise&amp;&amp; rhs);
34803 </pre>
34804 <blockquote>
34805 <p>
34806 <del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
34807 </p>
34808 <p>
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>
34813 </p>
34814 </blockquote>
34815 </blockquote>
34816
34817
34818
34819
34820
34821
34822 <hr>
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>
34830
34831 <p><b>Addresses UK 340</b></p>
34832
34833 <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.
34837 </p>
34838
34839 <p><i>[
34840 Summit:
34841 ]</i></p>
34842
34843
34844 <blockquote>
34845 <p>
34846 Agree, move to Review.
34847 </p>
34848 </blockquote>
34849
34850 <p><i>[
34851 2009-04-03 Thomas J. Gritzan adds:
34852 ]</i></p>
34853
34854
34855 <blockquote>
34856 <p>
34857 <tt>promise::get_future()</tt> must not invalidate the state of the promise object. 
34858 </p>
34859 <p>
34860 A promise is used like this: 
34861 </p>
34862 <blockquote><pre>promise&lt;int&gt; p; 
34863 unique_future&lt;int&gt; 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>
34867 <p>
34868 So <tt>get_future()</tt> must return an object that shares the same associated 
34869 state with <tt>*this</tt>. 
34870 </p>
34871 <p>
34872 But still, this function should throw an <tt>future_already_retrieved</tt> error 
34873 when it is called twice. 
34874 </p>
34875 <p>
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. 
34879 </p>
34880 <p>
34881 Suggested resolution: 
34882 </p>
34883 <p>
34884 Replace p12/p13 30.6.5 [futures.promise]: 
34885 </p>
34886 <blockquote>
34887 <p>
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>.
34890 </p>
34891 <p>
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>.
34896 </p>
34897 <p>
34898 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
34899 </p>
34900 </blockquote>
34901 <p>
34902 Replace p14 30.6.10 [futures.task]: 
34903 </p>
34904 <blockquote>
34905 <p>
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.
34908 </p>
34909
34910 <p><ins>
34911 <i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with 
34912 the task has already been retrieved. 
34913 </ins></p>
34914 <p>
34915 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
34916 </p>
34917 </blockquote>
34918 </blockquote>
34919
34920 <p><i>[
34921 Batavia (2009-05):
34922 ]</i></p>
34923
34924 <blockquote>
34925 Keep in Review status
34926 pending Detlef's forthcoming paper on futures.
34927 </blockquote>
34928
34929 <p><i>[
34930 2009-10 Santa Cruz:
34931 ]</i></p>
34932
34933
34934 <blockquote>
34935 NAD Editorial.  Solved by
34936 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
34937 </blockquote>
34938
34939
34940
34941 <p><b>Proposed resolution:</b></p>
34942 <p>
34943 Add after p13 30.6.5 [futures.promise]:
34944 </p>
34945
34946 <blockquote><pre>unique_future&lt;R&gt; get_future();
34947 </pre>
34948 <blockquote>
34949 <p>
34950 -13- ...
34951 </p>
34952 <p>
34953 <i>Postcondition:</i> <tt>*this</tt> has no associated state.
34954 </p>
34955 </blockquote>
34956 </blockquote>
34957
34958
34959
34960
34961
34962
34963 <hr>
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>
34969
34970 <p><b>Addresses UK 279</b></p>
34971
34972 <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
34976 standard. 
34977 </p>
34978
34979 <p>
34980 Proposal: Specify the return type using either decltype or the Iter concept_map.
34981 </p>
34982
34983 <p><i>[
34984 Summit:
34985 ]</i></p>
34986
34987
34988 <blockquote>
34989 <p>
34990 Under discussion. This is a general question about all iterator
34991 adapters.
34992 </p>
34993 </blockquote>
34994
34995 <p><i>[
34996 Howard adds post Summit:
34997 ]</i></p>
34998
34999
35000 <blockquote>
35001 I am requesting test cases to demonstrate a position.
35002 </blockquote>
35003
35004 <p><i>[
35005 2009-07-24 Daniel adds:
35006 ]</i></p>
35007
35008
35009 <blockquote>
35010 <p>
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
35014 </p>
35015 <blockquote><pre>static const Iter&amp; __base(); // not defined
35016 auto operator[](difference_type n) const -&gt; decltype(__base()[-n-1]);
35017 </pre></blockquote>
35018
35019 <p>
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.
35024 </p>
35025
35026 </blockquote>
35027
35028 <p><i>[
35029 2009-10 Santa Cruz:
35030 ]</i></p>
35031
35032
35033 <blockquote>
35034 Moved to NAD.
35035 </blockquote>
35036
35037 <p><i>[
35038 2009-10-22 Daniel adds:
35039 ]</i></p>
35040
35041
35042 <blockquote>
35043 <p>
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
35047 a trivial way".
35048 </p>
35049
35050 <p>
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.
35055 </p>
35056
35057 <p>
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.
35061 </p>
35062
35063 <p>
35064 It is now your own decision how to proceed ;-)
35065 </p>
35066
35067 <blockquote><pre>#include &lt;type_traits&gt;
35068 #include &lt;cstddef&gt;
35069
35070 template&lt;class T&gt;
35071 typename std::add_rvalue_reference&lt;T&gt;::type declval();
35072
35073 template&lt;class It&gt;
35074 struct reverse_iterator {
35075     It base;
35076     
35077     typedef std::ptrdiff_t difference_type;
35078     
35079     template&lt;class U = It, class Res =
35080      decltype(declval&lt;const U&amp;&gt;()[declval&lt;difference_type&gt;()])
35081     &gt;
35082     Res operator[](difference_type n) const  {
35083         return base[-n-1];
35084     }    
35085 };
35086
35087 struct MyIter {
35088 };
35089
35090 int main() {
35091     reverse_iterator&lt;int*&gt; ri;
35092     ri[0] = 2;
35093     reverse_iterator&lt;MyIter&gt; ri2;
35094 }
35095 </pre></blockquote>
35096
35097 <p>
35098 The above declaration could be simplified, but the ideal solution
35099 </p>
35100
35101 <blockquote><pre>template&lt;class U = It&gt;
35102   decltype(declval&lt;const U&amp;&gt;()[declval&lt;difference_type&gt;()])
35103      operator[](difference_type n) const;
35104 </pre></blockquote>
35105
35106 <p>
35107 does not work yet on gcc 4.4.1.
35108 </p>
35109
35110 </blockquote>
35111
35112
35113
35114
35115 <p><b>Proposed resolution:</b></p>
35116
35117
35118
35119
35120
35121 <hr>
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>
35127
35128 <p><b>Addresses UK 281</b></p>
35129
35130 <p>
35131 The current specification for return value for <tt>reverse_iterator::operator-&gt;</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'.
35134 </p>
35135
35136 <p><i>[
35137 Summit:
35138 ]</i></p>
35139
35140
35141 <blockquote>
35142 <p>
35143 <tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
35144 Iterator type.
35145 study group formed to come up with a suggested resolution.
35146 </p>
35147 <p>
35148 <tt>move_iterator</tt> solution shown in proposed wording.
35149 </p>
35150 </blockquote>
35151
35152 <p><i>[
35153 2009-07 post-Frankfurt:
35154 ]</i></p>
35155
35156
35157 <blockquote>
35158 Howard to deconceptize. Move to Review after that happens.
35159 </blockquote>
35160
35161 <p><i>[
35162 2009-08-01 Howard deconceptized:
35163 ]</i></p>
35164
35165
35166 <blockquote>
35167 </blockquote>
35168
35169 <p><i>[
35170 2009-10 Santa Cruz:
35171 ]</i></p>
35172
35173
35174 <blockquote>
35175 <p>
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.
35179 </p>
35180 <p>
35181 Here is the proposed wording that was replaced:
35182 </p>
35183 <blockquote><pre>template &lt;class Iterator&gt; 
35184 class reverse_iterator { 
35185   ...
35186   typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
35187 </pre></blockquote>
35188
35189 <p>
35190 Change 24.5.1.3.5 [reverse.iter.opref]:
35191 </p>
35192
35193 <blockquote><pre>pointer operator-&gt;() const;
35194 </pre>
35195 <blockquote>
35196 <i>Returns:</i>
35197 <blockquote><pre><del>&amp;(operator*());</del>
35198 <ins>this-&gt;tmp = current;</ins>
35199 <ins>--this-&gt;tmp;</ins>
35200 <ins>return this-&gt;tmp;</ins>
35201 </pre></blockquote>
35202 </blockquote>
35203 </blockquote>
35204 </blockquote>
35205
35206 <p><i>[
35207 2010-03-03 Daniel opens:
35208 ]</i></p>
35209
35210
35211 <blockquote>
35212 <ol>
35213
35214 <li>
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.
35219 </li>
35220
35221 <li>
35222 <p>
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:
35227 </p>
35228
35229 <blockquote><pre>this-&gt;deref_tmp = current;
35230 --this-&gt;deref_tmp;
35231 return this-&gt;deref_tmp;
35232 </pre></blockquote>
35233
35234 <p>
35235 combined with the change of
35236 </p>
35237
35238 <blockquote><pre>typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
35239 </pre></blockquote>
35240
35241 <p>
35242 to
35243 </p>
35244
35245 <blockquote><pre>typedef Iterator pointer;
35246 </pre></blockquote>
35247
35248 <p>
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:
35252 </p>
35253
35254 <blockquote><pre>#include &lt;iterator&gt;
35255 #include &lt;utility&gt;
35256
35257 int main() {
35258   typedef std::pair&lt;int, double&gt; P;
35259   P op;
35260   std::reverse_iterator&lt;P*&gt; ri(&amp;op + 1);
35261   ri-&gt;first; // Error
35262 }
35263 </pre></blockquote>
35264
35265 <p>
35266 Comeau online returns (if a correspondingly changed
35267 <tt>reverse_iterator</tt> is used):
35268 </p>
35269
35270 <blockquote><pre>"error: expression must have class type
35271      return deref_tmp.operator-&gt;();
35272             ^
35273          detected during instantiation of "Iterator
35274                    reverse_iterator&lt;Iterator&gt;::operator-&gt;() const [with
35275                    Iterator=std::pair&lt;int, double&gt; *]""
35276 </pre></blockquote>
35277
35278 <p>
35279 Thus the change will break valid, existing code based
35280 on <tt>std::reverse_iterator</tt>.
35281 </p>
35282
35283 </li>
35284
35285 </ol>
35286
35287 <p>
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-&gt;</tt>
35291 overloads.
35292 </p>
35293
35294 <p>
35295 Suggested resolution:
35296 </p>
35297
35298 <ol>
35299
35300 <li>
35301 <p>
35302 In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator] change as indicated:
35303 </p>
35304
35305 <blockquote><pre>namespace std {
35306 template &lt;class Iterator&gt;
35307 class reverse_iterator : public
35308              iterator&lt;typename iterator_traits&lt;Iterator&gt;::iterator_category,
35309              typename iterator_traits&lt;Iterator&gt;::value_type,
35310              typename iterator_traits&lt;Iterator&gt;::difference_type,
35311              <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del>,
35312              typename iterator_traits&lt;Iterator&gt;::reference&gt; {
35313 public:
35314   [..]
35315   typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
35316   [..]
35317 protected:
35318   Iterator current;
35319 private:
35320   <ins>mutable</ins> Iterator deref_tmp; // exposition only
35321 };
35322 </pre></blockquote>
35323 </li>
35324
35325 <li>
35326 Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
35327
35328 <blockquote><pre>pointer operator-&gt;() const;
35329 </pre>
35330
35331 <blockquote>
35332 1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&amp;(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>
35337 </blockquote>
35338 </blockquote>
35339
35340 </li>
35341
35342 </ol>
35343
35344 </blockquote>
35345
35346 <p><i>[
35347 2010 Pittsburgh:
35348 ]</i></p>
35349
35350
35351 <blockquote>
35352 <p>
35353 We prefer to make to use a local variable instead of <tt>deref_tmp</tt> within
35354 <tt>operator-&gt;()</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.
35357 </p>
35358
35359 <p>
35360 Here is the proposed wording that was replaced:
35361 </p>
35362
35363 <blockquote class="note">
35364 <p>
35365 Change 24.5.1.3.5 [reverse.iter.opref]:
35366 </p>
35367
35368 <blockquote><pre>pointer operator-&gt;() const;
35369 </pre>
35370
35371 <blockquote>
35372
35373 <i>Returns:</i>
35374 <blockquote><pre><del>&amp;(operator*());</del>
35375 <ins>deref_tmp = current;
35376 --deref_tmp;
35377 return deref_tmp::operator-&gt;();</ins>
35378 </pre></blockquote>
35379
35380 </blockquote>
35381 </blockquote>
35382
35383
35384 </blockquote>
35385 </blockquote>
35386
35387 <p><i>[
35388 2010-03-10 Howard adds:
35389 ]</i></p>
35390
35391
35392 <blockquote>
35393 <p>
35394 Here are three tests that the current proposed wording passes, and no
35395 other solution I've seen passes all three:
35396 </p>
35397
35398 <ol>
35399 <li>
35400 <p>
35401 Proxy pointer support:
35402 </p>
35403 <blockquote><pre>#include &lt;iterator&gt;
35404 #include &lt;cassert&gt;
35405
35406 struct X { int m; };
35407
35408 X x;
35409
35410 struct IterX {
35411     typedef std::bidirectional_iterator_tag iterator_category;
35412     typedef X&amp; reference;
35413     struct pointer
35414     {
35415         pointer(X&amp; v) : value(v) {}
35416         X&amp; value;
35417         X* operator-&gt;() const {return &amp;value;}
35418     };
35419     typedef std::ptrdiff_t difference_type;
35420     typedef X value_type;
35421     // additional iterator requirements not important for this issue
35422     
35423     reference operator*() const { return x; }
35424     pointer operator-&gt;() const { return pointer(x); }
35425     IterX&amp; operator--() {return *this;}
35426
35427 };
35428
35429 int main()
35430 {
35431     std::reverse_iterator&lt;IterX&gt; ix;
35432     assert(&amp;ix-&gt;m == &amp;(*ix).m);
35433 }
35434 </pre></blockquote>
35435 </li>
35436 <li>
35437 <p>
35438 Raw pointer support:
35439 </p>
35440 <blockquote><pre>#include &lt;iterator&gt;
35441 #include &lt;utility&gt;
35442
35443 int main() {
35444   typedef std::pair&lt;int, double&gt; P;
35445   P op;
35446   std::reverse_iterator&lt;P*&gt; ri(&amp;op + 1);
35447   ri-&gt;first; // Error
35448 }
35449 </pre></blockquote>
35450 </li>
35451 <li>
35452 <p>
35453 Caching iterator support:
35454 </p>
35455 <blockquote><pre>#include &lt;iterator&gt;
35456 #include &lt;cassert&gt;
35457
35458 struct X { int m; };
35459
35460 struct IterX {
35461     typedef std::bidirectional_iterator_tag iterator_category;
35462     typedef X&amp; 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
35467     
35468     reference operator*() const { return value; }
35469     pointer operator-&gt;() const { return &amp;value; }
35470     IterX&amp; operator--() {return *this;}
35471
35472 private:
35473     mutable X value;
35474 };
35475
35476 int main()
35477 {
35478     std::reverse_iterator&lt;IterX&gt; ix;
35479     assert(&amp;ix-&gt;m == &amp;(*ix).m);
35480 }
35481 </pre></blockquote>
35482 </li>
35483 </ol>
35484 </blockquote>
35485
35486 <p><i>[
35487 2010 Pittsburgh:
35488 ]</i></p>
35489
35490
35491 <blockquote>
35492 Moved to NAD Future, rationale added.
35493 </blockquote>
35494
35495
35496
35497
35498 <p><b>Rationale:</b></p>
35499 <p>
35500 The LWG did not reach a consensus for a change to the WP.
35501 </p>
35502
35503
35504 <p><b>Proposed resolution:</b></p>
35505
35506 <ol>
35507
35508 <li>
35509 <p>
35510 In the class template <tt>reverse_iterator</tt> synopsis of 24.5.1.1 [reverse.iterator] change as indicated:
35511 </p>
35512
35513 <blockquote><pre>namespace std {
35514 template &lt;class Iterator&gt;
35515 class reverse_iterator : public
35516              iterator&lt;typename iterator_traits&lt;Iterator&gt;::iterator_category,
35517              typename iterator_traits&lt;Iterator&gt;::value_type,
35518              typename iterator_traits&lt;Iterator&gt;::difference_type,
35519              <del>typename iterator_traits&lt;</del>Iterator<ins>&amp;</ins><del>&gt;::pointer</del>,
35520              typename iterator_traits&lt;Iterator&gt;::reference&gt; {
35521 public:
35522   [..]
35523   typedef <del>typename iterator_traits&lt;</del>Iterator<ins>&amp;</ins><del>&gt;::pointer</del> pointer;
35524   [..]
35525 protected:
35526   Iterator current;
35527 private:
35528   <ins>mutable</ins> Iterator deref_tmp; // exposition only
35529 };
35530 </pre></blockquote>
35531 </li>
35532
35533 <li>
35534 Change 24.5.1.3.5 [reverse.iter.opref]/1 as indicated:
35535
35536 <blockquote><pre>pointer operator-&gt;() const;
35537 </pre>
35538
35539 <blockquote>
35540 1 <i><del>Returns</del> <ins>Effects</ins>:</i> <del><tt>&amp;(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>
35545 </blockquote>
35546 </blockquote>
35547
35548 </li>
35549
35550 </ol>
35551
35552
35553
35554
35555
35556
35557
35558
35559
35560
35561 <hr>
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>
35568
35569 <p><b>Addresses UK 295</b></p>
35570
35571 <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
35576 inconsistencies.
35577 </p>
35578 <p>
35579 Proposed resolution: Adopt
35580 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
35581 </p>
35582
35583 <p><i>[
35584 Summit:
35585 ]</i></p>
35586
35587
35588 <blockquote>
35589 <p>
35590 NAD, this change would break code that takes the address of an
35591 algorithm.
35592 </p>
35593 </blockquote>
35594
35595 <p><i>[
35596 Post Summit Alisdair adds:
35597 ]</i></p>
35598
35599
35600 <blockquote>
35601 <p>
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.
35606 </p>
35607
35608 <p>
35609 For me (personally) that was the more important part of the paper, and not
35610 clearly addressed by the Summit resolution.
35611 </p>
35612 </blockquote>
35613
35614 <p><i>[
35615 2009-10 Santa Cruz:
35616 ]</i></p>
35617
35618
35619 <blockquote>
35620 Too inventive, too late, would really need a paper. Moved to NAD Future.
35621 </blockquote>
35622
35623
35624
35625 <p><b>Proposed resolution:</b></p>
35626
35627
35628
35629
35630
35631 <hr>
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>
35638
35639 <p>
35640 Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
35641 requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
35642 </p>
35643 <p>
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.
35648 </p>
35649 <p>
35650 These constraints should be dropped, and applied to specific algorithms as
35651 needed.
35652 </p>
35653 <p>
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.
35657 </p>
35658
35659 <p><i>[
35660 Batavia (2009-05):
35661 ]</i></p>
35662
35663 <blockquote>
35664 Move to Open.
35665 </blockquote>
35666
35667 <p><i>[
35668 2009-05-31 Alisdair adds:
35669 ]</i></p>
35670
35671
35672 <blockquote>
35673 <p>
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
35676 facility.
35677 </p>
35678 <p>
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.
35687 </p>
35688 <p>
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
35696 today.
35697 </p>
35698 </blockquote>
35699
35700 <p><i>[
35701 2009-11-03 Alisdair adds:
35702 ]</i></p>
35703
35704
35705 <blockquote>
35706 <p>
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.
35709 </p>
35710 <p>
35711 The agreement in SC was that I would provide you with the rationale (see
35712 below) to include when moving to NAD.
35713 </p>
35714 </blockquote>
35715
35716 <p><i>[
35717 2009-11-03 Howard adds:
35718 ]</i></p>
35719
35720
35721 <blockquote>
35722 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
35723 </blockquote>
35724
35725
35726 <p><b>Proposed resolution:</b></p>
35727
35728
35729 <p><b>Rationale:</b></p>
35730 <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.
35737 </p>
35738
35739 <p>
35740 We concur, and expect this to have no repurcussions re-writing this
35741 clause now concepts are removed.
35742 </p>
35743
35744
35745
35746
35747
35748 <hr>
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>
35755
35756 <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.
35760 </p>
35761 <p>
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.
35765 </p>
35766 <p>
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).
35770 </p>
35771 <p>
35772 The preference is to create a single new algorithm and retain the value of
35773 the existing documentation.
35774 </p>
35775
35776 <p><i>[
35777 Batavia (2009-05):
35778 ]</i></p>
35779
35780 <blockquote>
35781 <p>
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.
35785 </p>
35786 <p>
35787 Alisdair disagrees as to the concept's value as documentation.
35788 </p>
35789 <p>
35790 Marc points out that the <tt>RandomNumberDistribution</tt>
35791 is also a concept not used elsewhere in the Standard.
35792 </p>
35793 <p>
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.
35797 </p>
35798 <p>
35799 Move to Open.
35800 </p>
35801 </blockquote>
35802
35803
35804 <p><b>Proposed resolution:</b></p>
35805
35806
35807
35808
35809
35810 <hr>
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>
35817
35818 <p>
35819 Sequence containers 23.2.3 [sequence.reqmts]:
35820 </p>
35821
35822 <p>
35823 The return value of new calls added to table 83 are not specified.
35824 </p>
35825
35826 <p><i>[
35827 Batavia (2009-05):
35828 ]</i></p>
35829
35830 <blockquote>
35831 <p>
35832 We agree with the proposed resolution.
35833 </p>
35834 <p>
35835 Move to NAD Editorial.
35836 </p>
35837 </blockquote>
35838
35839
35840 <p><b>Proposed resolution:</b></p>
35841 <p>
35842 Add after p6 23.2.3 [sequence.reqmts]:
35843 </p>
35844
35845 <blockquote>
35846 <p>
35847 -6- ...
35848 </p>
35849 <p><ins>
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>.
35852 </ins></p>
35853 <p><ins>
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>.
35856 </ins></p>
35857 </blockquote>
35858
35859
35860
35861
35862
35863 <hr>
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>
35870 <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>
35874 shortly
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>)
35877 had been
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>&lt;functional&gt;</tt> synopsis and
35881 20.8.14.2 [func.wrap.func]).
35882 </p>
35883 <p>
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.
35887 </p>
35888 <p>
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
35892 code.
35893 </p>
35894 <p>
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
35900 </p>
35901 <blockquote><pre>template&lt;typename T&gt;
35902 requires ReferentType&lt;T&gt; // Eliminate cv void and function types with cv-qual-seq
35903                          //   or ref-qual (depending on core issue #749)
35904       &amp;&amp; PointeeType&lt;T&gt;  // Eliminate reference types
35905       &amp;&amp; !ObjectType&lt;T&gt;  // Eliminate object types
35906 </pre></blockquote>
35907 <p>
35908 Just for completeness approach (c), which would make sense, if the
35909 library has more reasons to constrain for free function types:
35910 </p>
35911 <blockquote><pre>auto concept FreeFunctionType&lt;typename T&gt;
35912   : ReferentType&lt;T&gt;, PointeeType&lt;T&gt;, MemberPointeeType&lt;T&gt;
35913 {
35914   requires !ObjectType&lt;T&gt;;
35915 }
35916 </pre></blockquote>
35917 <p>
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>.
35921 </p>
35922
35923 <p><i>[
35924 Batavia (2009-05):
35925 ]</i></p>
35926
35927 <blockquote>
35928 <p>
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
35934 be changed.
35935 </p>
35936 <p>
35937 Bill feels this category of entity would change sufficiently slowly
35938 that he would be willing to take the risk.
35939 </p>
35940 <p>
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.
35944 </p>
35945 <p>
35946 We would like to have this issue reviewed by Core and would like
35947 their feedback.  Move to Open.
35948 </p>
35949 </blockquote>
35950
35951
35952 <p><b>Proposed resolution:</b></p>
35953 <ol>
35954 <li>
35955 <p>
35956 Change in 20.8 [function.objects]/2, Header <tt>&lt;functional&gt;</tt> synopsis:
35957 </p>
35958 <blockquote><pre>// 20.6.16 polymorphic function wrappers:
35959 class bad_function_call;
35960 template&lt;<del>FunctionType</del><ins>ReferentType F</ins>&gt;
35961 <ins>requires PointeeType&lt;F&gt; &amp;&amp; !ObjectType&lt;F&gt;</ins>
35962 class function; // undefined
35963 </pre></blockquote>
35964 </li>
35965 <li>
35966 <p>
35967 Change in 20.8.14.2 [func.wrap.func]:
35968 </p>
35969 <blockquote><pre>namespace std {
35970 template&lt;<del>FunctionType</del><ins>ReferentType F</ins>&gt;
35971 <ins>requires PointeeType&lt;F&gt; &amp;&amp; !ObjectType&lt;F&gt;</ins>
35972 class function; // undefined
35973 </pre></blockquote>
35974 </li>
35975 </ol>
35976
35977
35978
35979
35980
35981 <hr>
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>
35987
35988 <p>
35989 Definition of null-terminated sequences allow for embedded nulls. This is
35990 surprising, and probably not supportable with the intended use cases.
35991 </p>
35992
35993 <p><i>[
35994 Batavia (2009-05):
35995 ]</i></p>
35996
35997 <blockquote>
35998 We agree with the issue, but believe this can be handled editorially.
35999 Move to NAD Editorial.
36000 </blockquote>
36001
36002
36003
36004 <p><b>Proposed resolution:</b></p>
36005
36006
36007
36008
36009
36010 <hr>
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>
36016
36017 <p>
36018 The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if
36019 given a negative integer.
36020 </p>
36021
36022 <p><i>[
36023 Batavia (2009-05):
36024 ]</i></p>
36025
36026 <blockquote>
36027 Move to NAD Editorial.
36028 </blockquote>
36029
36030
36031
36032 <p><b>Proposed resolution:</b></p>
36033 <p>
36034 20.3.5.4 [pair.astuple] p5:
36035 </p>
36036
36037 <blockquote><pre>template&lt;<del>int</del> <ins>size_t</ins> I, class T1, class T2&gt; 
36038   requires True&lt;(I &lt; 2)&gt; 
36039   const P&amp; get(const pair&lt;T1, T2&gt;&amp;);
36040 </pre>
36041 </blockquote>
36042
36043
36044
36045
36046
36047
36048 <hr>
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>
36055
36056 <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.
36061 </p>
36062
36063 <p>
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>.
36067 </p>
36068
36069 <p><i>[
36070 Batavia (2009-05):
36071 ]</i></p>
36072
36073 <blockquote>
36074 <p>
36075 Walter recommends NAD Future.
36076 </p>
36077 <p>
36078 Move to Open, and recommend deferring the issue until after the next
36079 Committee Draft is issued.
36080 </p>
36081 </blockquote>
36082
36083 <p><i>[
36084 2009-07-29 Howard moves to Tentatively NAD Future.
36085 ]</i></p>
36086
36087
36088 <blockquote>
36089 A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
36090 </blockquote>
36091
36092 <p><i>[
36093 2009 Santa Cruz:
36094 ]</i></p>
36095
36096
36097 <blockquote>
36098 Moved to NAD.  The intent of these adapters are to restrict the interfaces.
36099 </blockquote>
36100
36101
36102
36103 <p><b>Proposed resolution:</b></p>
36104
36105
36106
36107
36108
36109 <hr>
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>
36115
36116 <p>
36117 Which header must a user <tt>#include</tt> to obtain the library-supplied
36118 <tt>concept_maps</tt> declared in this paragraph?
36119 </p>
36120
36121 <p>
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>&lt;algorithm&gt;</tt>.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a> for more details.
36126 </p>
36127
36128 <p><i>[
36129 Batavia (2009-05):
36130 ]</i></p>
36131
36132 <blockquote>
36133 We agree with the direction of the proposed resolution.
36134 Move to Tentatively Ready.
36135 </blockquote>
36136
36137 <p><i>[
36138 2009-07 Frankfurt
36139 ]</i></p>
36140
36141
36142 <blockquote>
36143 We believe this is NAD Concepts, but this needs to be reviewed against the
36144 post-remove-concepts draft.
36145 </blockquote>
36146
36147
36148 <p><b>Proposed resolution:</b></p>
36149 <p><i>Change  [depr.lib.iterator.primitives], Iterator primitives, as
36150 indicated:</i></p>
36151
36152 <blockquote>
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>&lt;iterator&gt;</tt>.</ins></p>
36157 </blockquote>
36158 <p><i>Change X [iterator.backward], Iterator backward compatibility, as
36159 indicated:</i></p>
36160 <blockquote>
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>
36165 </blockquote>
36166
36167
36168
36169
36170
36171 <hr>
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>
36177
36178 <p><b>Addresses UK 152</b></p>
36179
36180 <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
36184 </p>
36185
36186 <p><i>[
36187 Summit:
36188 ]</i></p>
36189
36190 <blockquote>
36191 We think we're removing this; See X [func.referenceclosure.cons].
36192 </blockquote>
36193
36194 <p><i>[
36195 2009-10 Santa Cruz:
36196 ]</i></p>
36197
36198
36199 <blockquote>
36200 Mark as NAD.  This will not affect user or implementer code
36201 </blockquote>
36202
36203
36204
36205 <p><b>Proposed resolution:</b></p>
36206 <p>
36207 </p>
36208
36209
36210
36211
36212
36213 <hr>
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>
36219
36220 <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.
36227 </p>
36228 <p>
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.
36232 </p>
36233
36234 <p><i>[
36235 2009-05-02 Daniel adds:
36236 ]</i></p>
36237
36238
36239 <blockquote>
36240 <p>
36241 one part of the suggested resolution suggests the removal of the
36242 <tt>MoveConstructible&lt;T&gt;</tt> requirement from
36243 <tt>inner_product</tt>. According to 26.7.2 [inner.product]
36244 </p>
36245
36246 <blockquote>
36247 Computes its result by initializing the accumulator <tt>acc</tt> with the
36248 initial value <tt>init</tt>
36249 </blockquote>
36250
36251 <p>
36252 this step requires at least <tt>MoveConstructible</tt>.
36253 </p>
36254
36255 <p>
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&lt;T&gt;</tt> requirement).
36259 </p>
36260 </blockquote>
36261
36262 <p><i>[
36263 Batavia (2009-05):
36264 ]</i></p>
36265
36266 <blockquote>
36267 <p>
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.
36271 </p>
36272 <p>
36273 Move to Tentatively Ready.
36274 </p>
36275 </blockquote>
36276
36277
36278 <p><b>Proposed resolution:</b></p>
36279 <p>
36280 Change in 26.7 [numeric.ops] and 26.7.1 [accumulate]:
36281 </p>
36282
36283 <blockquote><pre>template &lt;InputIterator Iter, MoveConstructible T&gt;
36284  requires <ins>add =</ins> HasPlus&lt;T, Iter::reference&gt;
36285        &amp;&amp; HasAssign&lt;T, <del>HasPlus&lt;T, Iter::reference&gt;</del> <ins>add</ins>::result_type&gt;
36286  T accumulate(Iter first, Iter last, T init);
36287 </pre></blockquote>
36288
36289 <p>
36290 Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
36291 </p>
36292
36293 <blockquote><pre>template &lt;InputIterator Iter1, InputIterator Iter2, MoveConstructible T&gt;
36294   requires <ins>mult =</ins> HasMultiply&lt;Iter1::reference, Iter2::reference&gt;
36295         &amp;&amp; <ins>add =</ins> HasPlus&lt;T, <del>HasMultiply&lt;Iter1::reference, Iter2::reference&gt;</del> <ins>mult</ins>::result_type&gt;
36296         &amp;&amp; HasAssign&lt; 
36297              T,
36298              <del>HasPlus&lt;T,
36299                      HasMultiply&lt;Iter1::reference, Iter2::reference&gt;::result_type&gt;</del> <ins>add</ins>::result_type&gt;
36300   T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
36301 </pre></blockquote>
36302
36303 <p>
36304 Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
36305 </p>
36306
36307 <blockquote><pre>template &lt;InputIterator InIter, OutputIterator&lt;auto, const InIter::value_type&amp;&gt; OutIter&gt;
36308   requires <ins>add =</ins> HasPlus&lt;InIter::value_type, InIter::reference&gt;
36309         &amp;&amp; HasAssign&lt;InIter::value_type,
36310                      <del>HasPlus&lt;InIter::value_type, InIter::reference&gt;</del> <ins>add</ins>::result_type&gt;
36311         &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
36312   OutIter partial_sum(InIter first, InIter last, OutIter result);
36313 </pre></blockquote>
36314
36315 <p>
36316 Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
36317 </p>
36318
36319 <blockquote><pre>template &lt;InputIterator InIter, OutputIterator&lt;auto, const InIter::value_type&amp;&gt; OutIter&gt;
36320   requires <ins>sub =</ins> HasMinus&lt;InIter::value_type, InIter::value_type&gt;
36321         &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
36322         &amp;&amp; OutputIterator&lt;OutIter, <del>HasMinus&lt;InIter::value_type, InIter::value_type&gt;</del> <ins>sub</ins>::result_type&gt;
36323         &amp;&amp; MoveAssignable&lt;InIter::value_type&gt;
36324   OutIter adjacent_difference(InIter first, InIter last, OutIter result);
36325 </pre></blockquote>
36326
36327
36328
36329
36330
36331
36332 <hr>
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>
36339
36340 <p>
36341 class <tt>random_device</tt> should be movable.
36342 </p>
36343
36344 <p><i>[
36345 Batavia (2009-05):
36346 ]</i></p>
36347
36348 <blockquote>
36349 Move to Open, and recommend this issue be deferred until after the next
36350 Committee Draft is issued.
36351 </blockquote>
36352
36353 <p><i>[
36354 2009-10 post-Santa Cruz:
36355 ]</i></p>
36356
36357
36358 <blockquote>
36359 Leave open. Walter to provide drafting as part of his planned paper.
36360 </blockquote>
36361
36362 <p><i>[
36363 2010 Pittsburgh:  Moved to NAD.
36364 ]</i></p>
36365
36366
36367
36368
36369 <p><b>Rationale:</b></p>
36370 <p>
36371 WP is correct as written.
36372 </p>
36373
36374
36375 <p><b>Proposed resolution:</b></p>
36376
36377
36378
36379
36380
36381 <hr>
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>
36388
36389 <p>
36390 class <tt>seed_seq</tt> should support efficient move operations.
36391 </p>
36392
36393 <p><i>[
36394 Batavia (2009-05):
36395 ]</i></p>
36396
36397 <blockquote>
36398 Move to Open, and recommend this issue be deferred until after the next
36399 Committee Draft is issued.
36400 </blockquote>
36401
36402 <p><i>[
36403 2009-10 post-Santa Cruz:
36404 ]</i></p>
36405
36406
36407 <blockquote>
36408 Leave open. Walter to provide drafting as part of his planned paper.
36409 </blockquote>
36410
36411 <p><i>[
36412 2010 Pittsburgh:
36413 ]</i></p>
36414
36415
36416 <blockquote>
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
36419 with this.
36420 </blockquote>
36421
36422
36423
36424 <p><b>Proposed resolution:</b></p>
36425
36426
36427
36428
36429
36430 <hr>
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>
36437
36438 <p>
36439 Is <tt>std::hash</tt> a constrained template or not?
36440 </p>
36441 <p>
36442 According to Class template hash 20.8.15 [unord.hash], the definition is:
36443 </p>
36444
36445 <blockquote><pre>template &lt;class T&gt;
36446 struct hash : public std::unary_function&lt;T, std::size_t&gt; {
36447   std::size_t operator()(T val) const;
36448 };
36449 </pre></blockquote>
36450
36451 <p>
36452 And so unconstrained.
36453 </p>
36454 <p>
36455 According to the <tt>&lt;functional&gt;</tt> synopsis in p2 Function objects
36456 20.8 [function.objects] the template is declared as:
36457 </p>
36458
36459 <blockquote><pre>template &lt;ReferentType T&gt; struct hash;
36460 </pre></blockquote>
36461
36462 <p>
36463 which would make hash a constrained template.
36464 </p>
36465
36466 <p><i>[
36467 2009-03-22 Daniel provided wording.
36468 ]</i></p>
36469
36470
36471 <p><i>[
36472 Batavia (2009-05):
36473 ]</i></p>
36474
36475 <blockquote>
36476 <p>
36477 Alisdair is not certain that Daniel's proposed resolution is sufficient,
36478 and recommends we leave the hash template unconstrained for now.
36479 </p>
36480 <p>
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.
36484 </p>
36485 <p>
36486 Move to Open.
36487 </p>
36488 </blockquote>
36489
36490
36491 <p><b>Proposed resolution:</b></p>
36492
36493 <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>]
36496 </p>
36497
36498 <ol>
36499 <li>
36500 <p>
36501 In 20.8 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, change as indicated:
36502 </p>
36503
36504 <blockquote><pre>// 20.6.17, hash function base template:
36505 template &lt;ReferentType T&gt; struct hash; <ins>// undefined</ins>
36506 </pre></blockquote>
36507 </li>
36508 <li>
36509 <p>
36510 In 20.8.15 [unord.hash]/1 change as indicated:
36511 </p>
36512 <blockquote><pre>namespace std {
36513  <del>template &lt;class T&gt;
36514  struct hash : public std::unary_function&lt;T, std::size_t&gt; {
36515  std::size_t operator()(T val) const;
36516  };</del>
36517  <ins>template &lt;ReferentType T&gt; struct hash; // undefined</ins>
36518 }
36519 </pre></blockquote>
36520 </li>
36521 <li>
36522 <p>
36523 In 20.8.15 [unord.hash]/2 change as indicated:
36524 </p>
36525
36526 <blockquote>
36527 -2-  <ins>For all library-provided specializations, the template
36528 instantiation <tt>hash&lt;T&gt;</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&lt;const hash&lt;T&gt;, const T&amp;&gt;</tt>. If <tt>T</tt> is an object
36532 type or reference to
36533   object, <tt>hash&lt;T&gt;</tt> shall be publicly derived from
36534 <tt>std::unary_function&lt;T, std::size_t&gt;</tt>.
36535   </ins> The return value of <tt>operator()</tt> is unspecified, except that
36536 equal arguments
36537   shall yield the same result. <tt>operator()</tt> shall not throw exceptions.
36538 </blockquote>
36539 </li>
36540 <li>
36541 <p>
36542 In 18.7 [support.rtti]/1, header <tt>&lt;typeinfo&gt;</tt> synopsis change as indicated:
36543 </p>
36544 <blockquote><pre>namespace std {
36545   class type_info;
36546   class type_index;
36547   template &lt;<del>class</del><ins>ReferentType</ins> T&gt; struct hash;
36548 </pre></blockquote>
36549 </li>
36550 </ol>
36551
36552
36553
36554
36555
36556 <hr>
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>
36562
36563 <p>
36564 p7 Allocator-related element concepts X [allocator.element.concepts]
36565 </p>
36566
36567 <p>
36568 The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt>
36569 specialization no longer matches the original concept:
36570 </p>
36571
36572 <blockquote><pre>template &lt;Allocator Alloc, class T, class ... Args&gt;
36573   requires HasConstructor&lt;T, Args...&gt;
36574     concept_map AllocatableElement&lt;Alloc, T, Args&amp;&amp;...&gt; {
36575       void construct_element(Alloc&amp; a, T* t, Args&amp;&amp;... args) {
36576         Alloc::rebind&lt;T&gt;(a).construct(t, forward(args)...);
36577       }
36578     }
36579 </pre></blockquote>
36580
36581 <p><i>[
36582 2009-03-23 Pablo adds:
36583 ]</i></p>
36584
36585
36586 <blockquote>
36587 Actually, this is incorrect,
36588 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
36589 says. "In section 
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).
36603 </blockquote>
36604
36605 <p><i>[
36606 2009-05-01 Daniel adds:
36607 ]</i></p>
36608
36609 <blockquote>
36610 <p>
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
36615 </p>
36616 <blockquote><pre>requires FreeStoreAllocatable&lt;T&gt;;
36617 void Alloc::construct(T*, Args&amp;&amp;...);
36618 </pre></blockquote>
36619 </blockquote>
36620
36621 <p><i>[
36622 Batavia (2009-05):
36623 ]</i></p>
36624
36625 <blockquote>
36626 <p>
36627 The affected code is no longer part of the Working Draft.
36628 </p>
36629 <p>
36630 Move to NAD.
36631 </p>
36632 </blockquote>
36633
36634
36635 <p><b>Proposed resolution:</b></p>
36636 <p>
36637 Change X [allocator.element.concepts]:
36638 </p>
36639
36640 <blockquote><pre>template &lt;Allocator Alloc, class T, class ... Args&gt;
36641   requires HasConstructor&lt;T, Args...&gt;
36642     concept_map AllocatableElement&lt;Alloc, T, Args&amp;&amp;...&gt; {
36643       void construct_element(<del>Alloc&amp; a,</del> T* t, Args&amp;&amp;... args) {
36644         Alloc::rebind&lt;T&gt;(a).construct(t, forward(args)...);
36645       }
36646     }
36647 </pre></blockquote>
36648
36649
36650
36651
36652
36653
36654 <hr>
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>
36660 <p>
36661 The class templates <tt>unary/binary_negate</tt> need constraining and move support.
36662 </p>
36663 <p>
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.
36669 </p>
36670 <p>
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.
36673 </p>
36674 <p>
36675 Do not consider the issue of forwarding mutable lvalues at this point,
36676 although remain open to another issue on the topic.
36677 </p>
36678
36679 <p><i>[
36680 2009-05-01 Daniel adds:
36681 ]</i></p>
36682
36683 <blockquote>
36684 <p>
36685 IMO the currently proposed resolution needs some updates
36686 because it is ill-formed at several places:
36687 </p>
36688
36689 <ol>
36690 <li>
36691 <p>
36692 In concept AdaptableUnaryFunction change
36693 </p>
36694 <blockquote><pre>typename X::result_type;
36695 typename X::argument_type;
36696 </pre></blockquote>
36697 <p>
36698 to
36699 </p>
36700 <blockquote><pre>Returnable result_type = typename X::result_type;
36701 typename argument_type = typename X::argument_type;
36702 </pre></blockquote>
36703 <p>
36704 [The replacement "Returnable result_type" instead of "typename
36705 result_type" is non-editorial, but maybe you prefer that as well]
36706 </p>
36707 </li>
36708 <li>
36709 <p>
36710 In concept AdaptableBinaryFunction change
36711 </p>
36712 <blockquote><pre>typename X::result_type;
36713 typename X::first_argument_type;
36714 typename X::second_argument_type;
36715 </pre></blockquote>
36716 <p>
36717 to
36718 </p>
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>
36723 <p>
36724 [The replacement "Returnable result_type" instead of "typename
36725 result_type" is non-editorial, but maybe you prefer that as well.]
36726 </p>
36727 </li>
36728
36729 <li>
36730 <p>
36731 In class unary/binary_function
36732 </p>
36733 <ol type="a">
36734 <li>
36735 I suggest to change "ReturnType" to "Returnable" in both cases.
36736 </li>
36737 <li>
36738 I think you want to replace the remaining occurrences of "Predicate" by "P"
36739 (in both classes in copy/move from a predicate)
36740 </li>
36741 </ol>
36742 </li>
36743 <li>
36744 <p>
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&lt;true&gt;") or just explicit as follows:
36749 </p>
36750 <ol type="a">
36751 <li>
36752 <blockquote><pre>template &lt;AdaptableUnaryFunction P&gt;
36753 requires Predicate&lt; P, P::argument_type&gt;
36754 unary_negate&lt;P&gt; not1(const P&amp;&amp; pred);
36755 template &lt;AdaptableUnaryFunction P&gt;
36756 requires Predicate&lt; P, P::argument_type &gt;
36757 unary_negate&lt;P&gt; not1(P&amp;&amp; pred);
36758 </pre>
36759 <blockquote>
36760 -3- Returns: unary_negate&lt;P&gt;(pred).
36761 </blockquote>
36762 </blockquote>
36763 <p>
36764 [Don't we want a move call for the second overload as in
36765 </p>
36766 <blockquote><pre>unary_negate&lt;P&gt;(std::move(pred))
36767 </pre></blockquote>
36768 <p>
36769 in the Returns clause ?]
36770 </p>
36771 </li>
36772 <li>
36773 <pre>template &lt;AdaptableBinaryFunction P&gt;
36774 requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
36775 binary_negate&lt;P&gt; not2(const P&amp; pred);
36776 template &lt;AdaptableBinaryFunction P&gt;
36777 requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
36778 binary_negate&lt;P&gt; not2(P&amp;&amp; pred);
36779 </pre>
36780 <p>
36781 -5- Returns: binary_negate&lt;P&gt;(pred).
36782 </p>
36783 <p>
36784 [Don't we want a move call for the second overload as in
36785 </p>
36786 <blockquote><pre>binary_negate&lt;P&gt;(std::move(pred))
36787 </pre></blockquote>
36788 <p>
36789 in the Returns clause ?]
36790 </p>
36791 </li>
36792 </ol>
36793 </li>
36794 </ol>
36795 </blockquote>
36796
36797 <p><i>[
36798 Batavia (2009-05):
36799 ]</i></p>
36800
36801 <blockquote>
36802 <p>
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.
36806 </p>
36807 <p>
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.
36811 </p>
36812 <p>
36813 Move to Open.
36814 </p>
36815 </blockquote>
36816
36817 <p><i>[
36818 2009-10 post-Santa Cruz:
36819 ]</i></p>
36820
36821
36822 <blockquote>
36823 Leave open pending the potential move constructor paper. Note that
36824 we consider the "constraining" part NAD Concepts.
36825 </blockquote>
36826
36827 <p><i>[
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:
36830 ]</i></p>
36831
36832
36833 <blockquote class="note">
36834 <p>
36835 Add new concepts where appropriate::
36836 </p>
36837
36838 <blockquote><pre>auto concept AdaptableUnaryFunction&lt; typename X &gt; {
36839   typename X::result_type;
36840   typename X::argument_type;
36841 }
36842
36843 auto concept AdaptableBinaryFunction&lt; typename X &gt; {
36844   typename X::result_type;
36845   typename X::first_argument_type;
36846   typename X::second_argument_type;
36847 }
36848 </pre></blockquote>
36849
36850 <p>
36851 Revise as follows:
36852 </p>
36853
36854 <p>
36855 Base X [base] (Only change is constrained Result)
36856 </p>
36857
36858 <blockquote>
36859 <p>
36860 -1-  The following classes are provided to simplify the typedefs of the
36861 argument and result types:
36862 </p>
36863 <pre>namespace std {
36864   template &lt;class Arg, <del>class</del> <ins>ReturnType</ins> Result&gt;
36865   struct unary_function {
36866      typedef Arg    argument_type;
36867      typedef Result result_type;
36868   };
36869
36870   template &lt;class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result&gt;
36871   struct binary_function {
36872      typedef Arg1   first_argument_type;
36873      typedef Arg2   second_argument_type;
36874      typedef Result result_type;
36875   };
36876 }
36877 </pre></blockquote>
36878
36879 <p>
36880 Negators 20.8.9 [negators]:
36881 </p>
36882
36883 <blockquote>
36884 <p>
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).
36887 </p>
36888
36889 <pre>template &lt;<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>&gt;
36890   <ins>requires Predicate&lt; P, P::argument_type &gt;</ins>
36891   class unary_negate
36892     : public unary_function&lt;<del>typename</del> P<del>redicate</del>::argument_type,bool&gt; {
36893   public:
36894     <ins>unary_negate(const unary_negate &amp; ) = default;</ins>
36895     <ins>unary_negate(unary_negate &amp;&amp; );</ins>
36896
36897     <ins>requires CopyConstructible&lt; P &gt;</ins>
36898        explicit unary_negate(const Predicate&amp; pred); 
36899     <ins>requires MoveConstructible&lt; P &gt;
36900        explicit unary_negate(Predicate &amp;&amp; pred);</ins>
36901
36902     bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type&amp; x) const;
36903   };
36904 </pre>
36905 <blockquote>
36906 -2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
36907 </blockquote>
36908
36909 <pre>template &lt;class Predicate&gt;
36910   unary_negate&lt;Predicate&gt; not1(const Predicate&amp;amp; pred);
36911 <ins>template &lt;class Predicate&gt;
36912   unary_negate&lt;Predicate&gt; not1(Predicate&amp;&amp; pred);</ins>
36913 </pre>
36914 <blockquote>
36915 -3-  <i>Returns:</i> <tt>unary_negate&lt;Predicate&gt;(pred)</tt>.
36916 </blockquote>
36917
36918 <pre>template &lt;<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> &gt;
36919   <ins>requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;</ins>
36920   class binary_negate
36921     : public binary_function&lt;<del>typename</del> P<del>redicate</del>::first_argument_type,
36922                               <del>typename</del> P<del>redicate</del>::second_argument_type, bool&gt; {
36923   public:
36924     <ins>biary_negate(const binary_negate &amp; ) = default;</ins>
36925     <ins>binary_negate(binary_negate &amp;&amp; );</ins>
36926
36927     <ins>requires CopyConstructible&lt; P &gt;</ins>
36928        explicit binary_negate(const Predicate&amp; pred);
36929     <ins>requires MoveConstructible&lt; P &gt;
36930        explicit binary_negate(const Predicate&amp; pred);</ins>
36931
36932     bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type&amp; x,
36933                     const <del>typename</del> P<del>redicate</del>::second_argument_type&amp; y) const;
36934   };
36935 </pre>
36936 <blockquote>
36937 -4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
36938 </blockquote>
36939
36940 <pre>template &lt;class Predicate&gt;
36941   binary_negate&lt;Predicate&gt; not2(const Predicate&amp; pred);
36942 <ins>template &lt;class Predicate&gt;
36943   binary_negate&lt;Predicate&gt; not2(Predicate&amp;&amp; pred);</ins>
36944 </pre>
36945
36946 <blockquote>
36947 -5- <i>Returns:</i> <tt>binary_negate&lt;Predicate&gt;(pred)</tt>.
36948 </blockquote>
36949 </blockquote>
36950
36951 </blockquote>
36952
36953
36954 <p><i>[
36955 2010 Rapperswil:
36956 ]</i></p>
36957
36958
36959 <blockquote>
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.
36961 </blockquote>
36962
36963
36964
36965 <p><b>Proposed resolution:</b></p>
36966
36967
36968
36969
36970
36971 <hr>
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>
36978 <p>
36979 Class template tuple 20.4.2 [tuple.tuple]:
36980 </p>
36981
36982 <blockquote><pre>template &lt;class... UTypes&gt;
36983   requires Constructible&lt;Types, const UTypes&amp;&gt;...
36984 template &lt;class... UTypes&gt;
36985   requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
36986 </pre></blockquote>
36987
36988 <p>
36989 Somebody needs to look at this and say what it should be.
36990 </p>
36991
36992 <p><i>[
36993 2009-03-21 Daniel provided wording.
36994 ]</i></p>
36995
36996
36997 <p><i>[
36998 Batavia (2009-05):
36999 ]</i></p>
37000
37001 <blockquote>
37002 The resolution looks correct; move to NAD Editorial.
37003 </blockquote>
37004
37005
37006 <p><b>Proposed resolution:</b></p>
37007 <p>
37008 In 20.4.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated:
37009 </p>
37010
37011 <blockquote><pre>template &lt;class... UTypes&gt;
37012   requires Constructible&lt;Types, const UTypes&amp;&gt;...
37013   <ins>tuple(const pair&lt;UTypes...&gt;&amp;);</ins>
37014 template &lt;class... UTypes&gt;
37015   requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
37016   <ins>tuple(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
37017 </pre></blockquote>
37018
37019 <p>
37020 [NB.: The corresponding prototypes do already exist in 20.4.2.1 [tuple.cnstr]/7+8]
37021 </p>
37022
37023
37024
37025
37026
37027 <hr>
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>
37033
37034 <p><b>Addresses DE 17</b></p>
37035
37036 <p>
37037 DE-17: 
37038 </p>
37039 <p>
37040 The class <tt>type_index</tt> should be removed; it provides no additional
37041 functionality beyond providing appropriate concept maps.
37042 </p>
37043
37044 <p><i>[
37045 2009-03-31 Peter adds:
37046 ]</i></p>
37047
37048
37049 <blockquote>
37050 <p>
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>.
37053 </p>
37054 <p>
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.
37061 </p>
37062 </blockquote>
37063
37064
37065
37066 <p><b>Proposed resolution:</b></p>
37067 <p>Modify the header &lt;typeinfo&gt; synopsis in 
37068   18.7 [support.rtti]p1 as follows:</p>
37069
37070 <blockquote><pre>namespace std { 
37071   class type_info; 
37072   <del>class type_index;</del>
37073   template &lt;class T&gt; struct hash;
37074   template&lt;&gt; struct hash&lt;<del>type_index</del><ins>const type_info *</ins>&gt; : public std::unary_function&lt;<del>type_index</del><ins>const type_info *</ins>, size_t&gt; {
37075     size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const;
37076   }<ins>;</ins>
37077   <ins>concept_map LessThanComparable&lt;const type_info *&gt; <i>see below</i></ins>
37078   class bad_cast; 
37079   class bad_typeid;
37080 }
37081 </pre></blockquote>
37082
37083 <p>Add the following new subsection</p>
37084 <blockquote>
37085 <p>
37086 <ins>18.7.1.1 Template specialization <code>hash&lt;const type_info *&gt;</code>
37087 [type.info.hash]</ins></p>
37088
37089 <pre><ins>size_t operator()(const type_info *x) const;</ins>
37090 </pre>
37091 <ol>
37092 <li><ins><i>Returns</i>: <code>x-&gt;hash_code()</code></ins></li>
37093 </ol>
37094 </blockquote>
37095
37096  <p>Add the following new subsection</p>
37097  <blockquote>
37098 <p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p>
37099
37100
37101 <pre><ins>concept_map LessThanComparable&lt;const type_info *&gt; {</ins>
37102   <ins>bool operator&lt;(const type_info *x, const type_info *y) { return x-&gt;before(*y); }</ins>
37103   <ins>bool operator&lt;=(const type_info *x, const type_info *y) { return !y-&gt;before(*x); }</ins>
37104   <ins>bool operator&gt;(const type_info *x, const type_info *y) { return y-&gt;before(*x); }</ins>
37105   <ins>bool operator&gt;=(const type_info *x, const type_info *y) { return !x-&gt;before(*y); }</ins>
37106 <ins>}</ins>
37107 </pre>
37108 <ol>
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>
37112 </ol>
37113 </blockquote>
37114
37115 <p>Remove section 20.13 [type.index]</p>
37116
37117
37118
37119
37120
37121 <hr>
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>
37127 <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>,
37134 decimals
37135 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a>
37136 indirectly
37137 via conversion to <tt>long long</tt>) also took care of such a feature.
37138 </p>
37139 <p>
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:
37143 </p>
37144 <blockquote><pre>{ difference_type m = n;
37145  if (m &gt;= 0) while (m--) ++r;
37146  else while (m++) --r;
37147  return r; }
37148 </pre></blockquote>
37149
37150 <p>
37151 Both while-loops take advantage of a contextual conversion to <tt>bool</tt>
37152 (Another problem is that the &gt;= comparison uses the no
37153 longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>).
37154 </p>
37155
37156 <b>Original proposed resolution:</b>
37157 <ol>
37158 <li>
37159 <p>
37160 In X [concept.arithmetic], add to the list of less refined
37161 concepts one further concept:
37162 </p>
37163
37164 <blockquote><pre>concept ArithmeticLike&lt;typename T&gt;
37165   : Regular&lt;T&gt;, LessThanComparable&lt;T&gt;, HasUnaryPlus&lt;T&gt;, HasNegate&lt;T&gt;,
37166     HasPlus&lt;T, T&gt;, HasMinus&lt;T, T&gt;, HasMultiply&lt;T, T&gt;, HasDivide&lt;T, T&gt;,
37167     HasPreincrement&lt;T&gt;, HasPostincrement&lt;T&gt;, HasPredecrement&lt;T&gt;,
37168     HasPostdecrement&lt;T&gt;,
37169     HasPlusAssign&lt;T, const T&amp;&gt;, HasMinusAssign&lt;T, const T&amp;&gt;,
37170     HasMultiplyAssign&lt;T, const T&amp;&gt;,
37171     HasDivideAssign&lt;T, const T&amp;&gt;<ins>, ExplicitlyConvertible&lt;T, bool&gt;</ins> {
37172 </pre></blockquote>
37173 </li>
37174 <li>
37175 <p>
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
37179 constructor]:
37180 </p>
37181 <blockquote><pre>{ difference_type m = n;
37182  if (m &gt;= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r;
37183  else while (m++) --r;
37184  return r; }
37185 </pre></blockquote>
37186 </li>
37187 </ol>
37188
37189 <p><i>[
37190 Batavia (2009-05):
37191 ]</i></p>
37192
37193 <blockquote>
37194 <p>
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.
37197 </p>
37198 <p>
37199 We do not agree that the cited effects clause is invalid,
37200 as it expresses intent rather than specific code.
37201 </p>
37202 <p>
37203 Move to Review, pending input from concepts experts.
37204 </p>
37205 </blockquote>
37206
37207
37208
37209 <p><b>Proposed resolution:</b></p>
37210 <p>
37211 In X [concept.arithmetic], add to the list of less refined
37212 concepts one further concept:
37213 </p>
37214
37215 <blockquote><pre>concept ArithmeticLike&lt;typename T&gt;
37216   : Regular&lt;T&gt;, LessThanComparable&lt;T&gt;, HasUnaryPlus&lt;T&gt;, HasNegate&lt;T&gt;,
37217     HasPlus&lt;T, T&gt;, HasMinus&lt;T, T&gt;, HasMultiply&lt;T, T&gt;, HasDivide&lt;T, T&gt;,
37218     HasPreincrement&lt;T&gt;, HasPostincrement&lt;T&gt;, HasPredecrement&lt;T&gt;,
37219     HasPostdecrement&lt;T&gt;,
37220     HasPlusAssign&lt;T, const T&amp;&gt;, HasMinusAssign&lt;T, const T&amp;&gt;,
37221     HasMultiplyAssign&lt;T, const T&amp;&gt;,
37222     HasDivideAssign&lt;T, const T&amp;&gt;<ins>, ExplicitlyConvertible&lt;T, bool&gt;</ins> {
37223 </pre></blockquote>
37224
37225
37226
37227
37228
37229 <hr>
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>
37237
37238 <p>
37239 All the containers use concepts for their iterator usage, exect for
37240 <tt>basic_string</tt>. This needs fixing.
37241 </p>
37242
37243 <p>
37244 Use concepts for iterator template parameters throughout the chapter.
37245 </p>
37246
37247 <p><i>[
37248 Summit:
37249 ]</i></p>
37250
37251 <blockquote>
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.
37255 </blockquote>
37256
37257
37258 <p><b>Proposed resolution:</b></p>
37259
37260
37261
37262
37263
37264 <hr>
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>
37272
37273 <p>
37274 <tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt>
37275 concept and change as follows.
37276 </p>
37277
37278 <blockquote><pre>template&lt;CodeConvert Codecvt, class Elem = wchar_t&gt;
37279   class wstring_convert {
37280 </pre></blockquote>
37281
37282 <p><i>[
37283 Summit:
37284 ]</i></p>
37285
37286 <blockquote>
37287 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
37288 </blockquote>
37289
37290
37291 <p><b>Proposed resolution:</b></p>
37292
37293
37294
37295
37296
37297 <hr>
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>
37305
37306 <p>
37307 <tt>InputIterator</tt> does not use concept.
37308 </p>
37309
37310 <p>
37311 <tt>OutputIterator</tt> does not use concept.
37312 </p>
37313
37314 <p>
37315 Comments include proposed wording.
37316 </p>
37317
37318 <p><i>[
37319 Summit:
37320 ]</i></p>
37321
37322 <blockquote>
37323 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
37324 </blockquote>
37325
37326
37327 <p><b>Proposed resolution:</b></p>
37328
37329
37330
37331
37332
37333 <hr>
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>
37341
37342 <p>
37343 A default implementation should be supplied for the post-increment
37344 operator to simplify implementation of iterators by users.
37345 </p>
37346
37347 <p>
37348 Copy the Effects clause into the concept description as the default
37349 implementation. Assumes a default value for postincrement_result
37350 </p>
37351
37352 <p><i>[
37353 Summit:
37354 ]</i></p>
37355
37356 <blockquote>
37357 Howard will open an issue.
37358 </blockquote>
37359
37360 <p><i>[
37361 2009-06-07 Daniel adds:
37362 ]</i></p>
37363
37364
37365 <blockquote>
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
37372 is in preparation.
37373 </blockquote>
37374
37375
37376 <p><b>Proposed resolution:</b></p>
37377 <p><i>[
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.
37380 ]</i></p>
37381
37382
37383 <p>
37384 Change 24.2.5 [forward.iterators]:
37385 </p>
37386
37387 <blockquote>
37388 <pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; { 
37389
37390   MoveConstructible postincrement_result;
37391   requires HasDereference&lt;postincrement_result&gt;
37392         &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;
37393
37394   postincrement_result operator++(X&amp; r, int)<del>;</del> <ins>{
37395      X tmp = r;
37396      ++r;
37397      return tmp;
37398   }</ins>
37399
37400   axiom MultiPass(X a, X b) { 
37401     if (a == b) *a == *b; 
37402     if (a == b) ++a == ++b; 
37403   } 
37404 }
37405 </pre></blockquote>
37406
37407
37408
37409
37410
37411
37412 <hr>
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>
37420
37421 <p>
37422 A default implementation should be supplied for the post-decrement
37423 operator to simplify implementation of iterators by users.
37424 </p>
37425
37426 <p>
37427 Copy the Effects clause into the concept description as the default
37428 implementation. Assumes a default value for postincrement_result
37429 </p>
37430
37431 <p><i>[
37432 Summit:
37433 ]</i></p>
37434
37435 <blockquote>
37436 Howard will open an issue.
37437 </blockquote>
37438
37439 <p><i>[
37440 2009-06-07 Daniel adds:
37441 ]</i></p>
37442
37443
37444 <blockquote>
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>.
37448 </blockquote>
37449
37450
37451 <p><b>Proposed resolution:</b></p>
37452
37453 <p>
37454 Change 24.2.6 [bidirectional.iterators]:
37455 </p>
37456
37457 <blockquote>
37458 <pre>concept BidirectionalIterator&lt;typename X&gt; : ForwardIterator&lt;X&gt; { 
37459   MoveConstructible postdecrement_result; 
37460   requires HasDereference&lt;postdecrement_result&gt; 
37461         &amp;&amp; Convertible&lt;HasDereference&lt;postdecrement_result&gt;::result_type, const value_type&amp;&gt; 
37462         &amp;&amp; Convertible&lt;postdecrement_result, const X&amp;&gt;; 
37463   X&amp; operator--(X&amp;); 
37464   postdecrement_result operator--(X&amp; <ins>r</ins>, int)<del>;</del> <ins>{
37465      X tmp = r;
37466      --r;
37467      return tmp;
37468   }</ins>
37469 }
37470 </pre></blockquote>
37471
37472
37473
37474
37475
37476
37477 <hr>
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>
37484
37485 <p>
37486 The stream iterators need constraining with concepts/requrires clauses.
37487 </p>
37488
37489 <p><i>[
37490 Summit:
37491 ]</i></p>
37492
37493 <blockquote>
37494 We agree. To be handled by Howard, Martin and PJ.
37495 </blockquote>
37496
37497
37498 <p><b>Proposed resolution:</b></p>
37499
37500
37501
37502
37503
37504 <hr>
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>
37512
37513 <p>
37514 <tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator&lt;Iter,
37515 Iter::reference&gt;</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&amp;</tt>s might be copied over existing
37518 elements (hence the <tt>OutputIterator&lt;Iter, const T&amp;&gt;</tt>.
37519 </p>
37520
37521 <p>
37522 Remove <tt>OutputIterator&lt;Iter, Iter::reference&gt;</tt> from <tt>replace</tt>
37523 and <tt>replace_if</tt>.
37524 </p>
37525
37526 <p><i>[
37527 Summit:
37528 ]</i></p>
37529
37530 <blockquote>
37531 We agree. To be handled by Howard.
37532 </blockquote>
37533
37534
37535 <p><b>Proposed resolution:</b></p>
37536 <p>
37537 Change in  [algorithms.syn] and 25.3.5 [alg.replace]:
37538 </p>
37539
37540 <blockquote><pre>template&lt;ForwardIterator Iter, class T&gt; 
37541   requires <del>OutputIterator&lt;Iter, Iter::reference&gt; 
37542         &amp;&amp;</del> OutputIterator&lt;Iter, const T&amp;&gt; 
37543         &amp;&amp; HasEqualTo&lt;Iter::value_type, T&gt; 
37544   void replace(Iter first, Iter last, 
37545                const T&amp; old_value, const T&amp; new_value); 
37546
37547 template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred, class T&gt; 
37548   requires <del>OutputIterator&lt;Iter, Iter::reference&gt; 
37549         &amp;&amp;</del> OutputIterator&lt;Iter, const T&amp;&gt; 
37550         &amp;&amp; CopyConstructible&lt;Pred&gt; 
37551   void replace_if(Iter first, Iter last,
37552                   Pred pred, const T&amp; new_value);
37553 </pre></blockquote>
37554
37555
37556
37557
37558
37559 <hr>
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>
37568
37569 <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.
37572 </p>
37573
37574 <p>
37575 Add a non-member overload <tt>void swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }</tt>
37576 </p>
37577
37578 <p><i>[
37579 Summit:
37580 ]</i></p>
37581
37582 <blockquote>
37583 Create an issue. Move to review, attention: Howard. Detlef will also
37584 look into it.
37585 </blockquote>
37586
37587 <p><i>[
37588 Post Summit Daniel provided wording.
37589 ]</i></p>
37590
37591
37592 <p><i>[
37593 2009-10 Santa Cruz:
37594 ]</i></p>
37595
37596
37597 <blockquote>
37598 NAD Editorial.  Solved by
37599 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
37600 </blockquote>
37601
37602
37603
37604 <p><b>Proposed resolution:</b></p>
37605 <ol>
37606 <li>
37607 <p>
37608 In 30.6.5 [futures.promise], before p.1, immediately after class template
37609 promise add:
37610 </p>
37611 <blockquote><pre><ins>
37612 template &lt;class R&gt;
37613 void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
37614 </ins>
37615 </pre></blockquote>
37616 </li>
37617 <li>
37618 <p>
37619 Change 30.6.5 [futures.promise]/10 as indicated (to fix a circular definition):
37620 </p>
37621 <blockquote>
37622 <p>
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>
37625 </p>
37626 <p>
37627 <ins><i>Throws:</i> Nothing.</ins>
37628 </p>
37629 </blockquote>
37630 </li>
37631 <li>
37632 <p>
37633 After the last paragraph in 30.6.5 [futures.promise] add the following
37634 prototype description:
37635 </p>
37636 <blockquote><pre><ins>
37637 template &lt;class R&gt;
37638 void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
37639 </ins></pre>
37640 <blockquote>
37641 <p>
37642 <ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
37643 </p>
37644 <p>
37645 <ins><i>Throws:</i> Nothing.</ins>
37646 </p>
37647 </blockquote>
37648 </blockquote>
37649 </li>
37650
37651 </ol>
37652
37653
37654
37655
37656
37657
37658 <hr>
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>
37665 <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
37670 swap.
37671 </p>
37672
37673 <p><i>[
37674 Batavia (2009-05):
37675 ]</i></p>
37676
37677 <blockquote>
37678 <p>
37679 Alisdair notes that paragraph 2 of the proposed resolution has already been
37680 applied in the current Working Draft.
37681 </p>
37682 <p>
37683 We note a pending <tt>future</tt>-related paper by Detlef;
37684 we would like to wait for this paper before proceeding.
37685 </p>
37686 <p>
37687 Move to Open.
37688 </p>
37689 </blockquote>
37690
37691 <p><i>[
37692 2009-05-24 Daniel removed part 2 of the proposed resolution.
37693 ]</i></p>
37694
37695
37696 <p><i>[
37697 2009-10 post-Santa Cruz:
37698 ]</i></p>
37699
37700
37701 <blockquote>
37702 Move to Tentatively Ready, removing bullet 3 from the proposed
37703 resolution but keeping the other two bullets.
37704 </blockquote>
37705
37706 <p><i>[
37707 2010 Pittsburgh:
37708 ]</i></p>
37709
37710
37711 <blockquote>
37712 Moved to NAD Editorial.  Rationale added below.
37713 </blockquote>
37714
37715
37716
37717 <p><b>Rationale:</b></p>
37718 <p>
37719 Solved by N3058.
37720 </p>
37721
37722
37723 <p><b>Proposed resolution:</b></p>
37724 <ol>
37725 <li>
37726 <p>
37727 In 30.6.10 [futures.task], immediately after the definition of class
37728 template packaged_task add:
37729 </p>
37730 <blockquote><pre><ins>
37731 template&lt;class R, class... Argtypes&gt;
37732 void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp;, packaged_task&lt;R(ArgTypes...)&gt;&amp;);
37733 </ins>
37734 </pre></blockquote>
37735 </li>
37736 </ol>
37737
37738 <ol start="4">
37739
37740 <li>
37741 <p>
37742 At the end of 30.6.10 [futures.task] (after p. 20), add add the following
37743 prototype description:
37744 </p>
37745
37746 <blockquote><pre><ins>
37747 template&lt;class R, class... Argtypes&gt;
37748 void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y);
37749 </ins></pre>
37750 <blockquote>
37751 <p><ins>
37752 <i>Effects:</i> <tt>x.swap(y)</tt>
37753 </ins></p>
37754 <p><ins>
37755 <i>Throws:</i> Nothing.
37756 </ins></p>
37757 </blockquote>
37758 </blockquote>
37759 </li>
37760 </ol>
37761
37762
37763
37764
37765
37766 <hr>
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>
37772
37773 <p><b>Addresses UK 246</b></p>
37774 <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].
37780 </p>
37781
37782 <p><i>[
37783 Beman adds:
37784 ]</i></p>
37785
37786
37787 <blockquote>
37788 Pete is clearly right that
37789 this one is technical rather than editorial.
37790 </blockquote>
37791
37792 <p><i>[
37793 Batavia (2009-05):
37794 ]</i></p>
37795
37796 <blockquote>
37797 <p>
37798 We agree with the proposed resolution.
37799 </p>
37800 <p>
37801 Move to Review.
37802 </p>
37803 </blockquote>
37804
37805 <p><i>[
37806 2009-10 Santa Cruz:
37807 ]</i></p>
37808
37809
37810 <blockquote>
37811 Mark as NAD, solved by removing concepts.
37812 </blockquote>
37813
37814
37815
37816 <p><b>Proposed resolution:</b></p>
37817 <p>
37818 Strike 23.6.2.2 [multimap.modifiers] entirely
37819 (but do NOT strike these signatures from the class template definition!).
37820 </p>
37821
37822
37823
37824
37825
37826 <hr>
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>
37833 <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
37837 vice versa
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>.
37840 </p>
37841
37842 <p><i>[
37843 Batavia (2009-05):
37844 ]</i></p>
37845
37846 <blockquote>
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.
37852 </blockquote>
37853
37854
37855 <p><b>Proposed resolution:</b></p>
37856 <ol>
37857 <li>
37858 <p>
37859 In 20.7.2 [meta.type.synop], Header <tt>&lt;type_traits&gt;</tt>
37860 synopsis change as indicated:
37861 </p>
37862 <blockquote><pre>namespace std {
37863 // 20.5.3, helper class:
37864 template &lt;<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v&gt; struct integral_constant;
37865 </pre></blockquote>
37866 </li>
37867 <li>
37868 <p>
37869 In 20.7.3 [meta.help] change as indicated:
37870 </p>
37871 <blockquote><pre>template &lt;<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v&gt;
37872 struct integral_constant {
37873   static constexpr T value = v;
37874   typedef T value_type;
37875   typedef integral_constant&lt;T,v&gt; type;
37876   constexpr operator value_type() { return value; }
37877 };
37878 </pre></blockquote>
37879 </li>
37880 </ol>
37881
37882
37883
37884
37885
37886 <hr>
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>
37893
37894 <p>
37895 There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
37896 algorithm accepting a random number engine.
37897 </p>
37898
37899 <ol type="i">
37900 <li>
37901 The Iterators must be shuffle iterators, yet this requirement is missing.
37902 </li>
37903 <li>
37904 The <tt>RandomNumberEngine</tt> concept is now provided by the random number
37905 library
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.
37908 </li>
37909 </ol>
37910
37911 <p><i>[
37912 2009-05-02 Daniel adds:
37913 ]</i></p>
37914
37915
37916 <blockquote>
37917 <p>
37918 this issue completes adding necessary requirement to the
37919 third new <tt>random_shuffle</tt> overload. The current suggestion is:
37920 </p>
37921
37922 <blockquote><pre>template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
37923 requires ShuffleIterator&lt;Iter&gt;
37924 void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
37925 </pre></blockquote>
37926
37927 <p>
37928 IMO this is still insufficient and I suggest to add the requirement
37929 </p>
37930 <blockquote><pre>Convertible&lt;Rand::result_type, Iter::difference_type&gt;
37931 </pre></blockquote>
37932 <p>
37933 to the list (as the two other overloads already have).
37934 </p>
37935
37936 <p>
37937 Rationale:
37938 </p>
37939
37940 <blockquote>
37941 <p>
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&lt;result_type&gt;</tt>.
37946 </p>
37947 <p>
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.
37955 </p>
37956 <p>
37957 This argument leads us to the conclusion that we also need
37958 <tt>Convertible&lt;Rand::result_type, Iter::difference_type&gt;</tt> here.
37959 </p>
37960 </blockquote>
37961
37962 </blockquote>
37963
37964 <p><i>[
37965 Batavia (2009-05):
37966 ]</i></p>
37967
37968 <blockquote>
37969 <p>
37970 Alisdair notes that point (ii) has already been addressed.
37971 </p>
37972 <p>
37973 We agree with the proposed resolution to point (i)
37974 with Daniel's added requirement.
37975 </p>
37976 <p>
37977 Move to Review.
37978 </p>
37979 </blockquote>
37980
37981 <p><i>[
37982 2009-06-05 Daniel updated proposed wording as recommended in Batavia.
37983 ]</i></p>
37984
37985
37986 <p><i>[
37987 2009-07-28 Alisdair adds:
37988 ]</i></p>
37989
37990
37991 <blockquote>
37992 Revert to Open, with a note there is consensus on direction but the
37993 wording needs updating to reflect removal of concepts.
37994 </blockquote>
37995
37996 <p><i>[
37997 2009-10 post-Santa Cruz:
37998 ]</i></p>
37999
38000
38001 <blockquote>
38002 Leave Open, Walter to work on it.
38003 </blockquote>
38004
38005 <p><i>[
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>.
38008 ]</i></p>
38009
38010
38011
38012
38013 <p><b>Rationale:</b></p>
38014 <p>
38015 Solved by
38016 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3056.pdf">N3056</a>.
38017 </p>
38018
38019
38020 <p><b>Proposed resolution:</b></p>
38021 <p>
38022 Change in  [algorithms.syn] and 25.3.12 [alg.random.shuffle]:
38023 </p>
38024
38025 <blockquote><pre><del>concept UniformRandomNumberGenerator&lt;typename Rand&gt; { }</del>
38026 template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
38027   <ins>requires ShuffleIterator&lt;Iter&gt; &amp;&amp;
38028   Convertible&lt;Rand::result_type, Iter::difference_type&gt;</ins>
38029   void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
38030 </pre></blockquote>
38031
38032
38033
38034
38035
38036
38037 <hr>
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>
38045 <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.
38048 </p>
38049
38050 <p>
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.
38054 </p>
38055
38056 <p><i>[
38057 Batavia (2009-05):
38058 ]</i></p>
38059
38060 <blockquote>
38061 Move to Open, pending proposed wording from Dave for further review.
38062 </blockquote>
38063
38064
38065 <p><b>Proposed resolution:</b></p>
38066 <p>
38067 </p>
38068
38069
38070
38071
38072
38073 <hr>
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>
38081 <p>
38082 Notes
38083 </p>
38084 <blockquote>
38085 <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
38088 on 550
38089 </p>
38090
38091 <blockquote>
38092 <p>
38093 CD-1 reads:
38094 </p>
38095
38096 <blockquote><pre>template &lt;MoveConstructible T1, MoveConstructible T2&gt; 
38097 pair&lt;V1, V2&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;); 
38098 </pre></blockquote>
38099
38100 <p>
38101 Actually I'm guessing we need something like <tt>MoveConstructible&lt;V1,T1&gt;</tt>,
38102 i.e. "<tt>V1</tt> can be constructed from an rvalue of type <tt>T1</tt>."
38103 </p>
38104
38105 <p>
38106 Ditto for <tt>make_tuple</tt>
38107 </p>
38108 </blockquote>
38109
38110 <p>
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.  
38114 </p>
38115 <blockquote>
38116 <p>
38117    This issue may well be quite large.  Language in para 4 about "if
38118    an lvalue" is wrong because types aren't expressions.
38119 </p>
38120
38121 <blockquote>
38122 <p>
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 
38126 </p>
38127
38128 <blockquote><pre>F x(move(f))
38129 </pre></blockquote>
38130
38131 <p>
38132 is required to work.  That would cover both ctors at once.
38133 </p>
38134 </blockquote>
38135
38136 <p>
38137    p1199, call_once has all the same issues.
38138 </p>
38139 </blockquote>
38140 <p>
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-&gt; of its own that can be used for the value type.
38144 </p>
38145
38146 <blockquote>
38147 This one is serious and unrelated to the move issue.
38148 </blockquote>
38149
38150 <p>
38151 [2009-03-21 Sat] p818 stack has the same problem with default ctor.
38152 </p>
38153 <p>
38154 [2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
38155 </p>
38156 <blockquote><pre>   requires MoveConstructible&lt;Cont&gt; 
38157      explicit priority_queue(const Compare&amp; x = Compare(), Cont&amp;&amp; = Cont()); 
38158 </pre>
38159 <p>
38160    Don't require MoveConstructible when default constructing Cont.
38161    Also missing semantics for move ctor.
38162 </p>
38163 </blockquote>
38164 <p>
38165  [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
38166  opposed to MoveConstructible?
38167 </p>
38168 <p>
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!
38172 </p>
38173 <p>
38174  [2009-03-21 Sat] std::array should have constructors for C++0x,
38175  consequently must consider move construction.
38176 </p>
38177
38178 <p><i>[
38179 2009-05-01 Daniel adds:
38180 ]</i></p>
38181
38182
38183 <blockquote>
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.
38186 </blockquote>
38187
38188 <p>
38189  [2009-03-21 Sat] p622 all messed up.
38190 </p>
38191 <blockquote>
38192 <p>
38193    para 8 "implementation-defined" is the wrong term; should be "see
38194    below" or something.  
38195 </p>
38196 <p>
38197    para 12 "will be selected" doesn't make any sense because we're not
38198    talking about actual arg types.
38199 </p>
38200 <p>
38201    paras 9-13 need to be totally rewritten for concepts.
38202 </p>
38203 </blockquote>
38204
38205 <p>
38206  [2009-03-21 Sat] Null pointer comparisons (p587) have all become
38207  unconstrained.  Need to fix that
38208 </p>
38209 <p>
38210  [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
38211   We think CopyConstructible is the right reqt.
38212 </p>
38213 <p>
38214  make_pair needs Constructible&lt;V1, T1&amp;&amp;&gt; requirements!
38215 </p>
38216 <p>
38217  make_tuple needs something similar
38218 </p>
38219 <p>
38220  tuple bug in synopsis:
38221 </p>
38222 <blockquote><pre>   template &lt;class... UTypes&gt;
38223    requires Constructible&lt;Types, const UTypes&amp;&gt;...
38224    template &lt;class... UTypes&gt;
38225    requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
38226 </pre>
38227 <p>
38228    Note: removal of MoveConstructible requirements in std::function makes
38229    these routines unconstrained!
38230 </p>
38231 </blockquote>
38232
38233 <p><i>[
38234 2009-05-02 Daniel adds:
38235 ]</i></p>
38236
38237
38238 <blockquote>
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>.
38240 </blockquote>
38241
38242 <p>
38243  these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
38244 </p>
38245 <blockquote><pre> unique_ptr(pointer p, implementation-defined d);
38246  unique_ptr(pointer p, implementation-defined d);
38247 </pre></blockquote>
38248 <p>
38249  multimap range constructor should not have MoveConstructible&lt;value_type&gt; requirement.
38250 </p>
38251 <blockquote>
38252    same with insert(..., P&amp;&amp;); multiset has the same issue, as do
38253    unordered_multiset and unordered_multimap. Review these!
38254 </blockquote>
38255
38256 </blockquote>
38257
38258 <p><i>[
38259 Batavia (2009-05):
38260 ]</i></p>
38261
38262 <blockquote>
38263 Move to Open, pending proposed wording from Dave for further review.
38264 </blockquote>
38265
38266 <p><i>[
38267 2009-10 post-Santa Cruz:
38268 ]</i></p>
38269
38270
38271 <blockquote>
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.
38274 </blockquote>
38275
38276
38277
38278 <p><b>Rationale:</b></p>
38279 <p>
38280 The issue(s) at hand not adequately communicated.
38281 </p>
38282
38283
38284 <p><b>Proposed resolution:</b></p>
38285 <p>
38286 </p>
38287
38288
38289
38290
38291
38292 <hr>
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>
38299 <p>
38300 From Message c++std-core-14160 Howard wrote:
38301 </p>
38302
38303 <blockquote>
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>.
38306 </blockquote>
38307
38308 <p>
38309 And Pete replied:
38310 </p>
38311
38312 <blockquote>
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.
38316 </blockquote>
38317
38318 <p>
38319 My impression is that this overwrite was a simple (unintentional) mistake.
38320 Wording below to correct it.
38321 </p>
38322
38323 <p><i>[
38324 Batavia (2009-05):
38325 ]</i></p>
38326
38327 <blockquote>
38328 <p>
38329 Howard notes this issue resolves a discrepancy between the synopsis
38330 and the description.
38331 </p>
38332 <p>
38333 Move to NAD Editorial.
38334 </p>
38335 </blockquote>
38336
38337
38338 <p><b>Proposed resolution:</b></p>
38339 <p>
38340 Change 25.3.9 [alg.unique]:
38341 </p>
38342
38343 <blockquote><pre>template&lt;ForwardIterator Iter&gt; 
38344   requires OutputIterator&lt;Iter, <ins>RvalueOf&lt;</ins>Iter::reference<ins>&gt;::type</ins>&gt; 
38345         &amp;&amp; EqualityComparable&lt;Iter::value_type&gt; 
38346   Iter unique(Iter first, Iter last); 
38347
38348 template&lt;ForwardIterator Iter, EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred&gt; 
38349   requires OutputIterator&lt;Iter, RvalueOf&lt;Iter::reference&gt;::type&gt; 
38350         &amp;&amp; CopyConstructible&lt;Pred&gt; 
38351   Iter unique(Iter first, Iter last, Pred pred);
38352 </pre></blockquote>
38353
38354 <p>
38355 Note that the synopsis in  [algorithms.syn] is already correct.
38356 </p>
38357
38358
38359
38360
38361
38362
38363 <hr>
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>
38370 <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:
38379 </p>
38380
38381 <blockquote><pre>const int buf_size = ...;
38382 std::vector&lt;T&gt; buf(buf_size);
38383 for (int i = 0; i &lt; 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
38387 }
38388 </pre></blockquote>
38389 <p>
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.
38392 </p>
38393 <p>
38394 IMO the problem is due to the fact, that
38395 </p>
38396
38397 <ol type="a">
38398 <li>
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
38406 elements.
38407 </li>
38408 <li>
38409 <p>
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
38415 </p>
38416 <blockquote>
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.
38420 </blockquote>
38421 <p>
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
38429 own reading.
38430 </p>
38431 </li>
38432 </ol>
38433
38434 <p><i>[
38435 Batavia (2009-05):
38436 ]</i></p>
38437
38438 <blockquote>
38439 <p>
38440 Bill believes paragraph 1 of the proposed resolution is unnecessary
38441 because it is already implied (even if tortuously) by the current wording.
38442 </p>
38443 <p>
38444 Move to Review.
38445 </p>
38446 </blockquote>
38447
38448 <p><i>[
38449 2009-10 Santa Cruz:
38450 ]</i></p>
38451
38452
38453 <blockquote>
38454 Mark as NAD. Rationale: there is no consensus to clarify the standard,
38455 general consensus that the standard is correct as written.
38456 </blockquote>
38457
38458
38459
38460 <p><b>Proposed resolution:</b></p>
38461 <p><i>[
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
38468 ]</i></p>
38469
38470
38471 <ol>
38472 <li>
38473 <p>
38474 Change 23.4.1.2 [vector.capacity]/6 as follows:
38475 </p>
38476 <blockquote>
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>.
38481 </blockquote>
38482 </li>
38483 <li>
38484 <p>
38485 Change 23.4.1.4 [vector.modifiers]/4 as follows:
38486 </p>
38487 <blockquote>
38488 <i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
38489 happen.</ins>
38490 Invalidates iterators and references at or after the point
38491 of the erase.
38492 </blockquote>
38493 </li>
38494 </ol>
38495
38496
38497
38498
38499
38500 <hr>
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>
38506
38507 <p><i>[
38508 2009-04-26 Herb adds:
38509 ]</i></p>
38510
38511
38512 <blockquote>
38513 <p>
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&lt;T&gt;</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.
38521 </p>
38522 <p>
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
38525 at least this:
38526 </p>
38527 <blockquote><pre>template&lt;class T&gt; concept_map Range&lt;XYZCorpContainer&lt;T&gt;&gt; {};
38528
38529 template&lt;class T&gt; concept_map Range&lt;const XYZCorpContainer&lt;T&gt;&gt; {};
38530 </pre></blockquote>
38531 <p>
38532 Is that correct?
38533 </p>
38534 <p>
38535 But he may actually have to write this as we do for initializer list:
38536 </p>
38537 <blockquote><pre>template&lt;class T&gt;
38538 concept_map Range&lt;XYZCorpContainer&lt;T&gt;&gt; {
38539    typedef T* iterator;
38540    iterator begin(XYZCorpContainer&lt;T&gt; c) { return c.begin(); }
38541    iterator end(XYZCorpContainer&lt;T&gt; c) { return c.end(); }
38542 };
38543
38544 template&lt;class T&gt;
38545 concept_map Range&lt;const XYZCorpContainer&lt;T&gt;&gt; {
38546    typedef T* iterator;
38547    iterator begin(XYZCorpContainer&lt;T&gt; c) { return c.begin(); }
38548    iterator end(XYZCorpContainer&lt;T&gt; c) { return c.end(); }
38549 };
38550 </pre></blockquote>
38551
38552 </blockquote>
38553
38554 <p><i>[
38555 2009-04-28 Alisdair adds:
38556 ]</i></p>
38557
38558
38559 <blockquote>
38560 <p>
38561 I recommend NAD, although remain concerned about header organisation.
38562 </p>
38563 <p>
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.
38569 </p>
38570 <p>
38571 The problem is that they should now provide an additional two headers,
38572 <tt>&lt;iterator_concepts&gt;</tt> and <tt>&lt;container_concepts&gt;</tt>.
38573  The only difference from
38574 making <tt>Range</tt> an auto concept would be this reduces to a single header,
38575 <tt>&lt;iterator_concepts&gt;</tt>.
38576 </p>
38577 <p>
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.
38580 </p>
38581 </blockquote>
38582
38583 <p><i>[
38584 Batavia (2009-05):
38585 ]</i></p>
38586
38587 <blockquote>
38588 <p>
38589 We observe there is a recent paper by Bjarne that overlaps this issue.
38590 </p>
38591 <p>
38592 Alisdair continues to recommend NAD.
38593 </p>
38594 <p>
38595 Move to Open, and recommend the issue be deferred until after the next
38596 Committee Draft is issued.
38597 </p>
38598 </blockquote>
38599
38600
38601 <p><b>Proposed resolution:</b></p>
38602
38603
38604
38605
38606
38607 <hr>
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>
38614 <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.
38617 </p>
38618 <p>
38619 Paragraph 9 reads: 
38620 </p>
38621 <blockquote>
38622 <i>Throws:</i> the stored exception, if an exception was stored and not 
38623 retrieved before.
38624 </blockquote>
38625 <p>
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. 
38629 </p>
38630 <p>
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 
38634 stored. 
38635 </p>
38636
38637 <p><i>[
38638 Batavia (2009-05):
38639 ]</i></p>
38640
38641 <blockquote>
38642 <p>
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.
38646 </p>
38647 <p>
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.
38651 </p>
38652 <p>
38653 Move to Open.
38654 </p>
38655 </blockquote>
38656
38657 <p><i>[
38658 2010-01-23 Moved to Tentatively NAD Editorial after 5 positive votes on
38659 c++std-lib.
38660 ]</i></p>
38661
38662
38663
38664
38665 <p><b>Rationale:</b></p>
38666 <p>
38667 Resolved by paper
38668 <a href="file:///Users/hinnant/std%20documents/C++Mailings/papers/2009/n2997.htm">N2997</a>.
38669 </p>
38670
38671
38672 <p><b>Proposed resolution:</b></p>
38673 <p>
38674 Change 30.6.7 [futures.shared_future]:
38675 </p>
38676
38677 <blockquote><pre>const R&amp; shared_future::get() const; 
38678 R&amp; shared_future&lt;R&amp;&gt;::get() const; 
38679 void shared_future&lt;void&gt;::get() const;
38680 </pre>
38681 <blockquote>
38682 <p>...</p>
38683 <p>
38684 -9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
38685 <ins>
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>]
38689 </ins>
38690 </p>
38691 </blockquote>
38692 </blockquote>
38693
38694
38695
38696
38697
38698
38699 <hr>
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>
38706 <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 
38711 const value. 
38712 </p>
38713
38714 <p>
38715 I think that is a mistake and the constructor should take a r-value 
38716 reference: 
38717 </p>
38718
38719 <blockquote><pre>shared_future(unique_future&lt;R&gt;&amp;&amp; rhs);
38720 </pre></blockquote>
38721
38722 <p><i>[
38723 Batavia (2009-05):
38724 ]</i></p>
38725
38726 <blockquote>
38727 <p>
38728 We agree with the proposed resolution.
38729 </p>
38730 <p>
38731 Move to Tentatively Ready.
38732 </p>
38733 </blockquote>
38734
38735 <p><i>[
38736 2009-07-05 Daniel notes:
38737 ]</i></p>
38738
38739
38740 <blockquote>
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>.
38743 </blockquote>
38744
38745
38746 <p><b>Proposed resolution:</b></p>
38747 <p>
38748 Change the synopsis in 30.6.7 [futures.shared_future]:
38749 </p>
38750
38751 <blockquote><pre>shared_future(unique_future&lt;R&gt;<ins>&amp;&amp;</ins> rhs);
38752 </pre></blockquote>
38753
38754 <p>
38755 Change the definition of the constructor in 30.6.7 [futures.shared_future]:
38756 </p>
38757
38758 <blockquote><pre>shared_future(<del>const</del> unique_future&lt;R&gt;<ins>&amp;&amp;</ins> rhs);
38759 </pre></blockquote>
38760
38761
38762
38763
38764
38765
38766 <hr>
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>
38773 <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.
38778 </p>
38779
38780 <p><i>[
38781 Batavia (2009-05):
38782 ]</i></p>
38783
38784 <blockquote>
38785 We agree with the proposed resolution.
38786 Move to NAD Editorial.
38787 </blockquote>
38788
38789
38790 <p><b>Proposed resolution:</b></p>
38791 <p>
38792 Change  [algorithms.syn] and 25.4.5.1 [includes]:
38793 </p>
38794
38795 <blockquote><pre>template&lt;InputIterator Iter1, InputIterator Iter2,
38796          <del>typename</del> <ins>CopyConstructible</ins> Compare&gt;
38797   requires Predicate&lt;Compare, Iter1::value_type, Iter2::value_type&gt;
38798         &amp;&amp; Predicate&lt;Compare, Iter2::value_type, Iter1::value_type&gt;
38799   bool includes(Iter1 first1, Iter1 last1,
38800                 Iter2 first2, Iter2 last2,
38801                 Compare comp);
38802 </pre></blockquote>
38803
38804
38805
38806
38807
38808 <hr>
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>
38815 <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
38818 relation.
38819 </p>
38820
38821 <p>
38822 However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>,
38823 and not <tt>EquivalenceRelation</tt>.
38824 </p>
38825
38826 <p><i>[
38827 Batavia (2009-05):
38828 ]</i></p>
38829
38830 <blockquote>
38831 <p>
38832 We agree with the proposed resolution.
38833 </p>
38834 <p>
38835 Move to Review.
38836 </p>
38837 </blockquote>
38838
38839
38840 <p><b>Proposed resolution:</b></p>
38841 <p>
38842 For ordered containers, replace 
38843 </p>
38844 <blockquote><pre>Predicate&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
38845 </pre></blockquote>
38846 <p>
38847 with 
38848 </p>
38849 <blockquote><pre>StrictWeakOrder&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
38850 </pre></blockquote>
38851
38852 <p>
38853 For unordered containers, replace 
38854 </p>
38855 <blockquote><pre>Predicate&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
38856 </pre></blockquote>
38857 <p>
38858 with 
38859 </p>
38860 <blockquote><pre>EquivalenceRelation&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
38861 </pre></blockquote>
38862 <p>
38863 As in the following declarations:
38864 </p>
38865
38866 <blockquote>
38867 <p>
38868 Associative containers 23.6 [associative]
38869 </p>
38870 <p>
38871  1 Headers &lt;map&gt; and &lt;set&gt;:
38872 </p>
38873 <p>
38874    Header &lt;map&gt; synopsis
38875 </p>
38876 <blockquote><pre>   namespace std {
38877      template &lt;ValueType Key, ValueType T,
38878                <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38879                Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
38880        requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
38881              &amp;&amp; CopyConstructible&lt;Compare&gt;
38882              &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38883              &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38884      class map;
38885
38886      ...
38887
38888      template &lt;ValueType Key, ValueType T,
38889                <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38890                Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
38891        requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
38892              &amp;&amp; CopyConstructible&lt;Compare&gt;
38893              &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38894              &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38895      class multimap;
38896
38897      ...
38898
38899    }
38900 </pre></blockquote>
38901
38902 <p>
38903    Header &lt;set&gt; synopsis
38904 </p>
38905 <blockquote><pre>   namespace std {
38906      template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38907                Allocator Alloc = allocator&lt;Key&gt; &gt;
38908        requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
38909              &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38910              &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38911      class set;
38912
38913      ...
38914
38915      template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38916                Allocator Alloc = allocator&lt;Key&gt; &gt;
38917        requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
38918              &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38919              &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38920      class multiset;
38921
38922      ...
38923
38924    }
38925 </pre></blockquote>
38926
38927 <p>
38928  23.4.1p2 Class template map [map]
38929 </p>
38930 <blockquote><pre> namespace std {
38931    template &lt;ValueType Key, ValueType T,
38932              <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38933              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
38934      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
38935            &amp;&amp; CopyConstructible&lt;Compare&gt;
38936            &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38937            &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38938    class map {
38939      ...
38940    };
38941  }
38942 </pre></blockquote>
38943
38944
38945 <p>
38946  23.4.2p2 Class template multimap [multimap]
38947 </p>
38948 <blockquote><pre> namespace std {
38949    template &lt;ValueType Key, ValueType T,
38950              <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38951              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
38952      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
38953            &amp;&amp; CopyConstructible&lt;Compare&gt;
38954            &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38955            &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38956    class multimap {
38957      ...
38958    };
38959  }
38960 </pre></blockquote>
38961
38962
38963 <p>
38964  23.4.3p2 Class template set [set]
38965 </p>
38966 <blockquote><pre> namespace std {
38967    template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38968              Allocator Alloc = allocator&lt;Key&gt; &gt;
38969      requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
38970            &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38971            &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38972    class set {
38973      ...
38974    };
38975  }
38976 </pre></blockquote>
38977
38978
38979 <p>
38980  23.4.4p2 Class template multiset [multiset]
38981 </p>
38982 <blockquote><pre> namespace std {
38983    template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
38984              Allocator Alloc = allocator&lt;Key&gt; &gt;
38985      requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
38986            &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
38987            &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
38988    class multiset {
38989      ...
38990    };
38991  }
38992 </pre></blockquote>
38993
38994 <p>
38995  23.5 Unordered associative containers [unord]
38996 </p>
38997 <p>
38998  1 Headers &lt;unordered_map&gt; and &lt;unordered_set&gt;:
38999 </p>
39000 <p>
39001  Header &lt;unordered_map&gt; synopsis
39002 </p>
39003 <blockquote><pre> namespace std {
39004    // 23.5.1, class template unordered_map:
39005    template &lt;ValueType Key,
39006              ValueType T,
39007              Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
39008              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
39009              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
39010      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
39011            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39012            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39013            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39014            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39015            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39016            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39017      class unordered_map;
39018
39019    // 23.5.2, class template unordered_multimap:
39020    template &lt;ValueType Key,
39021              ValueType T,
39022              Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
39023              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
39024              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
39025      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
39026            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39027            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39028            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39029            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39030            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39031            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39032      class unordered_multimap;
39033
39034    ...
39035  }
39036 </pre></blockquote>
39037
39038 <p>
39039  Header &lt;unordered_set&gt; synopsis
39040 </p>
39041 <blockquote><pre> namespace std {
39042    // 23.5.3, class template unordered_set:
39043    template &lt;ValueType Value,
39044              Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
39045              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
39046              Allocator Alloc = allocator&lt;Value&gt; &gt;
39047      requires NothrowDestructible&lt;Value&gt;
39048            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39049            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39050            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39051            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39052            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39053            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39054      class unordered_set;
39055
39056    // 23.5.4, class template unordered_multiset:
39057    template &lt;ValueType Value,
39058              Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
39059              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
39060              Allocator Alloc = allocator&lt;Value&gt; &gt;
39061      requires NothrowDestructible&lt;Value&gt;
39062            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39063            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39064            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39065            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39066            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39067            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39068      class unordered_multiset;
39069
39070    ...
39071  }
39072 </pre></blockquote>
39073
39074 <p>
39075  23.5.1p3 Class template unordered_map [unord.map]
39076 </p>
39077 <blockquote><pre> namespace std {
39078    template &lt;ValueType Key,
39079              ValueType T,
39080              Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
39081              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
39082              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
39083      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
39084            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39085            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39086            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39087            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39088            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39089            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39090    class unordered_map
39091    {
39092      ...
39093    };
39094  }
39095 </pre></blockquote>
39096
39097 <p>
39098  23.5.2p3 Class template unordered_multimap [unord.multimap]
39099 </p>
39100 <blockquote><pre> namespace std {
39101    template &lt;ValueType Key,
39102              ValueType T,
39103              Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
39104              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
39105              Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
39106      requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
39107            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39108            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39109            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39110            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39111            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39112            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39113    class unordered_multimap
39114    {
39115      ...
39116    };
39117  }
39118 </pre></blockquote>
39119
39120 <p>
39121  23.5.3p3 Class template unordered_set [unord.set]
39122 </p>
39123 <blockquote><pre> namespace std {
39124    template &lt;ValueType Value,
39125              Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
39126              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
39127              Allocator Alloc = allocator&lt;Value&gt; &gt;
39128      requires NothrowDestructible&lt;Value&gt;
39129            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39130            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39131            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39132            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39133            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39134            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39135    class unordered_set
39136    {
39137      ...
39138    };
39139  }
39140 </pre></blockquote>
39141 <p>
39142  23.5.4p3 Class template unordered_multiset [unord.multiset]
39143 </p>
39144 <blockquote><pre> namespace std {
39145    template &lt;ValueType Value,
39146              Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
39147              <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
39148              Allocator Alloc = allocator&lt;Value&gt; &gt;
39149      requires NothrowDestructible&lt;Value&gt;
39150            &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
39151            &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
39152            &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
39153            &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
39154            &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
39155            &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
39156    class unordered_multiset
39157    {
39158      ...
39159    };
39160  }
39161 </pre></blockquote>
39162
39163 </blockquote>
39164
39165
39166
39167
39168
39169
39170 <hr>
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>
39177 <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
39181 loop.
39182 </p>
39183 <p>
39184 The obvious reason is that bitset does not support iterators.
39185 </p>
39186 <p>
39187 At least two reasonable solutions are available:
39188 </p>
39189 <ol type="i">
39190 <li>
39191 Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
39192 of <tt>std::array</tt>
39193 </li>
39194 <li>
39195 Provide an unspecified concept_map for <tt>Range&lt;bitset&gt;</tt>.
39196 </li>
39197 </ol>
39198 <p>
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>.
39204 </p>
39205 <p>
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
39208 in the long run.
39209 </p>
39210 <p>
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&lt;N&gt;::reference</tt>, or
39213 something else entirely?
39214 </p>
39215 <p>
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.
39219 </p>
39220
39221 <p><i>[
39222 Batavia (2009-05):
39223 ]</i></p>
39224
39225 <blockquote>
39226 Move to Open.
39227 We further recommend this be deferred until after the next Committee Draft.
39228 </blockquote>
39229
39230 <p><i>[
39231 2009-05-25 Alisdair adds:
39232 ]</i></p>
39233
39234
39235 <blockquote>
39236 <p>
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.
39239 </p>
39240
39241 <p><i>[
39242 Howard: I've replaced the proposed wording with Alisdair's suggestion.
39243 ]</i></p>
39244
39245
39246 </blockquote>
39247
39248 <p><i>[
39249 2009-07-24 Daniel modifies the proposed wording for non-concepts.
39250 ]</i></p>
39251
39252
39253 <p><i>[
39254 2009-10 post-Santa Cruz:
39255 ]</i></p>
39256
39257
39258 <blockquote>
39259 Mark as Tentatively NAD Future due to the loss of concepts.
39260 </blockquote>
39261
39262
39263
39264 <p><b>Rationale:</b></p>
39265 <p>
39266 All concepts-related text has been removed from the draft.
39267 </p>
39268
39269
39270 <p><b>Proposed resolution:</b></p>
39271 <ol>
39272 <li>
39273 <p>
39274 Modify the section 20.5 [template.bitset] <tt>&lt;bitset&gt;</tt> synopsis by adding
39275 the following at the end of the synopsis:
39276 </p>
39277 <blockquote><pre><ins>
39278 // XX.X.X bitset range access [bitset.range]
39279 template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
39280 template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
39281 template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
39282 template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
39283 </ins>
39284 </pre></blockquote>
39285 </li>
39286 <li>
39287 <p>
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
39290 paragraphs:
39291 </p>
39292 <blockquote>
39293 <p>
39294 <ins>
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&lt;N&gt;::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>.
39302 </ins>
39303 </p>
39304 <pre><ins>
39305 template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
39306 template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
39307 </ins>
39308 </pre>
39309 <blockquote>
39310 <ins>2.  Returns: an iterator referencing the first bit in the bitset.</ins>
39311 </blockquote>
39312
39313 <pre><ins>
39314 template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
39315 template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
39316 </ins></pre>
39317
39318 <blockquote>
39319 <ins>3.  Returns: an iterator referencing one past the last bit in the
39320 bitset.</ins>
39321 </blockquote>
39322 </blockquote>
39323 </li>
39324 </ol>
39325
39326
39327
39328
39329
39330
39331
39332
39333
39334
39335
39336
39337 <hr>
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>
39344 <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>&lt;cstdarg&gt;</tt> synopsis" (18.10 [support.runtime]), there is.
39348 </p>
39349
39350 <p><i>[
39351 2009-10 post-Santa Cruz:
39352 ]</i></p>
39353
39354
39355 <blockquote>
39356 Mark as Tentatively NAD Editorial, if Pete disagrees, Howard
39357 will move to Tentatively Ready
39358 </blockquote>
39359
39360
39361
39362 <p><b>Proposed resolution:</b></p>
39363 <p>
39364 Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
39365 </p>
39366
39367
39368
39369
39370
39371 <hr>
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>
39378 <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
39383 these APIs.
39384 </p>
39385 <p>
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
39390 Core/Evolution.
39391 </p>
39392 <p>
39393 Note that we have the same problem in numeric_limits.
39394 </p>
39395
39396 <p><i>[
39397 2009-10 post-Santa Cruz:
39398 ]</i></p>
39399
39400
39401 <blockquote>
39402 Move to Open. Alisdair to provide wording.
39403 </blockquote>
39404
39405
39406 <p><i>[
39407 2010 Rapperswil:
39408 ]</i></p>
39409
39410
39411 <blockquote>
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.
39413 </blockquote>
39414
39415
39416
39417 <p><b>Proposed resolution:</b></p>
39418
39419
39420
39421
39422
39423 <hr>
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>
39430 <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
39436 chain calls to
39437 <tt>remove_cv&lt;remove_reference&lt;T&gt;::type&gt;::type</tt>, and
39438 note that the order matters.
39439 </p>
39440 <p>
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.
39446 </p>
39447
39448 <p><i>[
39449 2009-10-14 Daniel adds:
39450 ]</i></p>
39451
39452
39453 <blockquote>
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>.
39462 </blockquote>
39463
39464 <p><i>[
39465 2009-10 Santa Cruz:
39466 ]</i></p>
39467
39468
39469 <blockquote>
39470 NAD Future.
39471 </blockquote>
39472
39473
39474
39475 <p><b>Proposed resolution:</b></p>
39476
39477
39478
39479
39480
39481 <hr>
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>
39488 <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
39492 ourselves.
39493 </p>
39494 <p>
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.
39499 </p>
39500 <p>
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
39503 equally useful.
39504 </p>
39505
39506 <p><i>[
39507 2009-10-30 Alisdair adds:
39508 ]</i></p>
39509
39510
39511 <blockquote>
39512 <p>
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.
39518 </p>
39519
39520 <p>
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.
39524 </p>
39525
39526 <p>
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.
39530 </p>
39531
39532 <p><i>[
39533 Alisdair updates wording.
39534 ]</i></p>
39535
39536
39537 </blockquote>
39538
39539 <p><i>[
39540 2009-10-30 Howard:
39541 ]</i></p>
39542
39543
39544 <blockquote>
39545 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
39546 </blockquote>
39547
39548
39549
39550 <p><b>Rationale:</b></p>
39551 <p>
39552 Does not have sufficient support at this time. May wish to reconsider for a
39553 future standard.
39554 </p>
39555
39556
39557 <p><b>Proposed resolution:</b></p>
39558
39559 <p>
39560 Add the following type traits to p3 20.6 [ratio]
39561 </p>
39562
39563 <blockquote><pre>// ratio arithmetic
39564 template &lt;class R1, class R2&gt; struct ratio_add;
39565 template &lt;class R1, class R2&gt; struct ratio_subtract;
39566 template &lt;class R1, class R2&gt; struct ratio_multiply;
39567 template &lt;class R1, class R2&gt; struct ratio_divide;
39568 <ins>template &lt;class R1, class ... RList&gt; struct ratio_sum;</ins>
39569 <ins>template &lt;class R1, class ... RList&gt; struct ratio_product;</ins>
39570 </pre></blockquote>
39571
39572 <p>
39573 after 20.6.2 [ratio.arithmetic] p1: add
39574 </p>
39575
39576 <blockquote><pre>template &lt;class R1, class ... RList&gt; struct ratio_sum; // declared, never defined
39577
39578 template &lt;class R1&gt; struct ratio_sum&lt;R1&gt; : R1 {};
39579 </pre>
39580
39581 <blockquote>
39582 <i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
39583 </blockquote>
39584
39585 <pre>template &lt;class R1, class R2, class ... RList&gt; 
39586  struct ratio_sum&lt;R1, R2, RList...&gt;
39587    : ratio_add&lt; R1, ratio_sum&lt;R2, RList...&gt;&gt; {
39588 };
39589 </pre>
39590
39591 <blockquote>
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>
39594 </blockquote>
39595 </blockquote>
39596
39597 <p>
39598 after 20.6.2 [ratio.arithmetic] p3: add
39599 </p>
39600
39601 <blockquote><pre>template &lt;class R1, class ... RList&gt; struct ratio_product; // declared, never defined
39602
39603 template &lt;class R1&gt; struct ratio_product&lt;R1&gt; : R1 {};
39604 </pre>
39605
39606 <blockquote>
39607 <i>Requires:</i> <tt>R1</tt> is a specialization of class template <tt>ratio</tt>
39608 </blockquote>
39609
39610 <pre>template &lt;class R1, class R2, class ... RList&gt; 
39611  struct ratio_sum&lt;R1, R2, RList...&gt;
39612    : ratio_add&lt; R1, ratio_product&lt;R2, RList...&gt;&gt; {
39613 };
39614 </pre>
39615
39616 <blockquote>
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>
39619 </blockquote>
39620 </blockquote>
39621
39622
39623
39624
39625
39626
39627
39628
39629 <hr>
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>
39636 <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.
39641 </p>
39642 <p>
39643 One problem of the concept <tt>RvalueOf</tt> as currently defined in
39644 X [concept.transform]:
39645 </p>
39646
39647 <blockquote><pre>concept RvalueOf&lt;typename T&gt; {
39648  typename type = T&amp;&amp;;
39649  requires ExplicitlyConvertible&lt;T&amp;,type&gt; &amp;&amp; Convertible&lt;T&amp;&amp;,type&gt;;
39650 }
39651
39652 template&lt;typename T&gt; concept_map RvalueOf&lt;T&amp;&gt; {
39653  typedef T&amp;&amp; type;
39654 }
39655 </pre></blockquote>
39656
39657 <p>
39658 is that if <tt>T</tt> is an lvalue-reference, the requirement
39659 <tt>Convertible&lt;T&amp;&amp;,type&gt;</tt> isn't satisfied for
39660 lvalue-references, because after reference-collapsing in the concept
39661 definition we have <tt>Convertible&lt;T&amp;,type&gt;</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
39666 type requirement.
39667 </p>
39668
39669
39670 <p><b>Proposed resolution:</b></p>
39671 <p>
39672 In X [concept.transform] before p. 4 change as indicated:
39673 </p>
39674
39675 <blockquote><pre>auto concept RvalueOf&lt;typename T&gt; {
39676   <del>typename</del><ins>RvalueReference</ins> type = T&amp;&amp;;
39677   requires <del>ExplicitlyConvertible&lt;T&amp;, type&gt; &amp;&amp; Convertible&lt;T&amp;&amp;, type&gt;</del><ins>SameType&lt;T&amp;, type&amp;&gt;</ins>;
39678 }
39679 </pre></blockquote>
39680
39681
39682
39683
39684
39685 <hr>
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>
39691 <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.
39696 </p>
39697
39698 <p><i>[
39699 2009-11-10 Howard adds:
39700 ]</i></p>
39701
39702
39703 <blockquote>
39704 Moved to Tentatively NAD after 5 positive votes on c++std-lib.  Rationale
39705 added below.
39706 </blockquote>
39707
39708
39709 <p><b>Proposed resolution:</b></p>
39710 <p>
39711 Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
39712 in 24.6.2 [ostream.iterator], para 2:
39713 </p>
39714
39715 <blockquote><pre>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(const T&amp; value);
39716 <ins>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(T&amp;&amp; value);</ins>
39717 </pre></blockquote>
39718
39719 <p>
39720 Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
39721 </p>
39722
39723 <blockquote>
39724 <pre>ostream_iterator&amp; operator=(T&amp;&amp; value);
39725 </pre>
39726 <blockquote>
39727 <p>
39728 -2- <i>Effects:</i>
39729 </p>
39730 <blockquote><pre>*out_stream &lt;&lt; std::move(value);
39731 if(delim != 0)
39732   *out_stream &lt;&lt; delim;
39733 return (*this);
39734 </pre></blockquote>
39735 </blockquote>
39736 </blockquote>
39737
39738
39739
39740 <p><b>Rationale:</b></p>
39741 <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
39745 lvalues.
39746 </p>
39747
39748
39749
39750
39751
39752 <hr>
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>
39759 <p>
39760 The deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained)
39761 iterators features the (exposition only) concept:
39762 </p>
39763
39764 <blockquote><pre>concept IsReference&lt;typename T&gt; { } // exposition only
39765 template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&gt; { }
39766 </pre></blockquote>
39767 <p>
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.
39774 </p>
39775 <p>
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.
39780 </p>
39781
39782
39783 <p><b>Proposed resolution:</b></p>
39784 <p>
39785 In Iterator traits 24.4.1 [iterator.traits] para 4 add:
39786 </p>
39787
39788 <blockquote><pre>concept IsReference&lt;typename T&gt; { } // exposition only
39789 template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&gt; { }
39790 <ins>template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&amp;&gt; { }</ins>
39791 </pre></blockquote>
39792
39793
39794
39795
39796
39797
39798 <hr>
39799 <h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits&lt;T*&gt;</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>
39804 <p>
39805 The <tt>&lt;iterator&gt;</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.
39809 </p>
39810 <p>
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.
39816 </p>
39817 <p>
39818 I can see two obvious solutions:
39819 </p>
39820
39821 <ol type="i">
39822 <li>
39823 Restore the <tt>iterator_traits&lt;T*&gt;</tt> partial specialization in D.10
39824 </li>
39825 <li>
39826 Remove the declaration of <tt>iterator_traits&lt;T*&gt;</tt> from 24.3 synopsis
39827 </li>
39828 </ol>
39829 <p>
39830 I recommend option (ii) in the wording below
39831 </p>
39832 <p>
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.
39837 </p>
39838
39839
39840 <p><b>Proposed resolution:</b></p>
39841 <p>
39842 In X [iterator.syn] strike:
39843 </p>
39844
39845 <blockquote><pre><del>template&lt;class T&gt; struct iterator_traits&lt;T*&gt;;</del>
39846 </pre></blockquote>
39847
39848
39849
39850
39851
39852
39853 <hr>
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>
39860 <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.
39870 </p>
39871
39872 <p><i>[
39873 2009-06-02 Daniel adds:
39874 ]</i></p>
39875
39876
39877 <blockquote>
39878 <p>
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.
39884 </p>
39885 <p>
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.
39896 </p>
39897 <p>
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!
39903 </p>
39904 <p>
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.
39908 </p>
39909 <p>
39910 Suggestion:
39911 </p>
39912 <ol>
39913 <li>
39914 <p>
39915 Change 24.6.1 [istream.iterator]/3 as indicated:
39916 </p>
39917 <blockquote><pre><ins>constexpr</ins> istream_iterator();
39918 istream_iterator(istream_type&amp; s);
39919 istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
39920 ~istream_iterator()<ins> = default</ins>;
39921 </pre></blockquote>
39922 </li>
39923 <li>
39924 <p>
39925 Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
39926 </p>
39927 <blockquote><pre><ins>constexpr</ins> istream_iterator();
39928 </pre>
39929 <blockquote>
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>
39932 </blockquote>
39933 </blockquote>
39934 </li>
39935 <li>
39936 <p>
39937 Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
39938 </p>
39939 <blockquote><pre>istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
39940 </pre>
39941 <blockquote>
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>
39944 </blockquote>
39945 </blockquote>
39946 </li>
39947 <li>
39948 <p>
39949 Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
39950 </p>
39951
39952 <blockquote><pre>~istream_iterator()<ins> = default</ins>;
39953 </pre>
39954 <blockquote>
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
39957 destructor.</ins>
39958 </blockquote>
39959 </blockquote>
39960 </li>
39961 <li>
39962 <p>
39963 Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
39964 </p>
39965
39966 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
39967 <ins>istreambuf_iterator(const istreambuf_iterator&amp;)  throw() = default;</ins>
39968 <ins>~istreambuf_iterator()  throw() = default;</ins>
39969 </pre></blockquote>
39970 </li>
39971 <li>
39972 <p>
39973 Change 24.6.3 [istreambuf.iterator]/1 as indicated:
39974 </p>
39975 <blockquote>
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>
39983 </blockquote>
39984 </li>
39985 </ol>
39986 </blockquote>
39987
39988 <p><i>[
39989 2009-10 Santa Cruz:
39990 ]</i></p>
39991
39992
39993 <blockquote>
39994 NAD Editorial.  Solved by
39995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
39996 </blockquote>
39997
39998
39999
40000 <p><b>Proposed resolution:</b></p>
40001 <p>
40002 24.6.1 [istream.iterator] para 3
40003 </p>
40004
40005 <blockquote><pre><ins>constexpr</ins> istream_iterator();
40006 </pre></blockquote>
40007
40008 <p>
40009 24.6.1.1 [istream.iterator.cons]
40010 </p>
40011
40012 <blockquote><pre><ins>constexpr</ins> istream_iterator();
40013 </pre>
40014 <blockquote>
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>
40018 </blockquote>
40019 </blockquote>
40020
40021 <p>
40022 24.6.3 [istreambuf.iterator]
40023 </p>
40024
40025 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
40026 </pre></blockquote>
40027
40028
40029
40030
40031
40032
40033 <hr>
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>
40041
40042 <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.
40045 </p>
40046 <p>
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>
40050 </p>
40051 <p>
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.
40055 </p>
40056 <p>
40057 List A (code of tree structured exception handling based on nested_exception
40058 in C++0x)
40059 </p>
40060
40061 <blockquote><pre>void A()
40062 {
40063     try
40064     {
40065         std::vector&lt;exception_ptr&gt; exception_list;
40066         try
40067         {
40068             // A_a() does a similar processing as A().
40069             A_a();
40070         }
40071         catch(...)
40072         {
40073             exception_list.push_back(current_exception());
40074         }
40075
40076         // ***The processing A() has to do even when A_a() fails. ***
40077         try
40078         {
40079             // A_b() does a similar processing as A().
40080             A_b();
40081         }
40082         catch(...)
40083         {
40084             exception_list.push_back(current_exception());
40085         }
40086         if (!exception_list.empty())
40087         {
40088             throw exception_list;
40089         }
40090     }
40091     catch(...)
40092     {
40093         throw_with_nested(A_exception("someone error"));
40094     }
40095 }
40096 void print_tree_exception(exception_ptr e, const std::string &amp; indent ="")
40097 {
40098     const char * indent_unit = " ";
40099     const char * mark = "- ";
40100     try
40101     {
40102         rethow_exception(e);
40103     }
40104     catch(const std::vector&lt;exception_ptr&gt; e)
40105     {
40106         for(std::vector&lt;exception_ptr&gt;::const_iterator i = e.begin(); i!=e.end(); ++i)
40107         {
40108             print_tree_exception(i, indent);
40109         }
40110     }
40111     catch(const std::nested_exception  e)
40112     {
40113         print_tree_exception(evil_i(e), indent +indent_unit);
40114     }
40115     catch(const std::exception e)
40116     {
40117         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; e.what() &lt;&lt; std::endl;
40118     }
40119     catch(...)
40120     {
40121         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; "unknown exception" &lt;&lt; std::endl;
40122     }
40123 }
40124 int main(int, char * [])
40125 {
40126     try
40127     {
40128         A();
40129     }
40130     catch()
40131     {
40132         print_tree_exception(current_exception());
40133     }
40134     return EXIT_SUCCESS;
40135 }
40136 </pre></blockquote>
40137
40138 <p>
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>.
40142 </p>
40143
40144 <blockquote><pre>void A()
40145 {
40146     tricklib::error_listener_type error_listener;
40147     // A_a() is like A(). A_a() can throw tree structured exception.
40148     A_a();
40149
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.
40152     A_b();
40153
40154     if (error_listener.has_error()) // You can write this "if block" in destructor
40155                                     //  of class derived from error_listener_type.
40156     {
40157         throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
40158     }
40159 }
40160 void print_tree_error(const tricklib::error_type &amp;a_error, const std::string &amp; indent = "")
40161 {
40162     const char * indent_unit = " ";
40163     const char * mark = "- ";
40164
40165     tricklib::error_type error = a_error;
40166     while(error)
40167     {
40168         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; error-&gt;message &lt;&lt; std::endl;
40169         if (error-&gt;children)
40170         {
40171             print_tree_error(error-&gt;children, indent +indent_unit);
40172         }
40173         error = error-&gt;next;
40174     }
40175 }
40176 int main(int, char * [])
40177 {
40178     tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
40179
40180     try
40181     {
40182         A();
40183     }
40184     catch(error_type error)
40185     {
40186         print_tree_error(error);
40187     }
40188     catch(...)
40189     {
40190         std::cout &lt;&lt; "- unknown exception" &lt;&lt; std::endl;
40191     }
40192     return EXIT_SUCCESS;
40193 }
40194 </pre></blockquote>
40195
40196 <p>
40197 Prospect
40198 </p>
40199 <p>
40200 We will focus on the method A() since the other methods, also main(), occur
40201 only once respectively.
40202 </p>
40203
40204 <ul>
40205 <li>
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.
40210 </li>
40211 <li>
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.
40215 </li>
40216 </ul>
40217
40218 <p>
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.
40222 </p>
40223 <p>
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>
40226 </p>
40227
40228 <p><i>[
40229 2009-10 Santa Cruz:
40230 ]</i></p>
40231
40232
40233 <blockquote>
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.
40237 </blockquote>
40238
40239
40240
40241 <p><b>Proposed resolution:</b></p>
40242 <p>
40243 </p>
40244
40245
40246
40247
40248
40249 <hr>
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>
40256
40257 <p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p>
40258
40259 <p>
40260 The thread chapter is not concept enabled.
40261 </p>
40262
40263
40264
40265 <p><b>Proposed resolution:</b></p>
40266
40267
40268
40269
40270
40271 <hr>
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>
40278
40279 <p><b>Addresses US 84</b></p>
40280
40281 <p>
40282 The numerics chapter is not concept enabled.
40283 </p>
40284
40285 <p>
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.
40289 </p>
40290
40291
40292
40293 <p><b>Proposed resolution:</b></p>
40294
40295
40296
40297
40298
40299 <hr>
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>
40306
40307 <p><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72, UK 308</b></p>
40308
40309 <p>
40310 The input/output chapter is not concept enabled.
40311 </p>
40312
40313
40314
40315 <p><b>Proposed resolution:</b></p>
40316
40317
40318
40319
40320
40321 <hr>
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>
40328
40329 <p><b>Addresses US 86, UK 309, UK 310</b></p>
40330
40331 <p>
40332 The regular expressions chapter is not concept enabled.
40333 </p>
40334
40335
40336
40337 <p><b>Proposed resolution:</b></p>
40338
40339
40340
40341
40342
40343 <hr>
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>
40351
40352 <p><b>Addresses US 87, UK 311</b></p>
40353
40354 <p>
40355 The atomics chapter is not concept enabled.
40356 </p>
40357
40358 <p>
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>.
40360 </p>
40361
40362 <p><i>[
40363 2009-10 Santa Cruz:
40364 ]</i></p>
40365
40366
40367 <blockquote>
40368 NAD Editorial.  Solved by
40369 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40370 </blockquote>
40371
40372
40373
40374 <p><b>Proposed resolution:</b></p>
40375
40376
40377
40378
40379
40380 <hr>
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>
40388
40389 <p><b>Addresses UK 312</b></p>
40390
40391 <p>
40392 The contents of the <tt>&lt;stdatomic.h&gt;</tt> header are not listed anywhere,
40393 and <tt>&lt;cstdatomic&gt;</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.
40396 </p>
40397
40398 <p><i>[
40399 2009-10 Santa Cruz:
40400 ]</i></p>
40401
40402
40403 <blockquote>
40404 NAD Editorial.  Solved by
40405 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40406 </blockquote>
40407
40408
40409
40410 <p><b>Proposed resolution:</b></p>
40411 <p>
40412 Remove <tt>&lt;cstdatomic&gt;</tt> from the C99 headers in table 14.
40413 Add a new header <tt>&lt;atomic&gt;</tt> to the headers in table 13.
40414 Update chapter 29 to remove reference to <tt>&lt;stdatomic.h&gt;</tt>
40415 and replace the use of <tt>&lt;cstdatomic&gt;</tt> with <tt>&lt;atomic&gt;</tt>.
40416 </p>
40417 <p><i>[
40418 If and when WG14 adds atomic operations to C
40419 we can add corresponding headers to table 14 with a TR.
40420 ]</i></p>
40421
40422
40423
40424
40425
40426
40427 <hr>
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>
40434
40435 <p><b>Addresses US 88</b></p>
40436
40437 <p>
40438 The "lockfree" facilities do not tell the programmer enough.
40439 </p>
40440
40441 <p>
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?)
40458 </p>
40459
40460 <p>
40461 Second, having <tt>atomic_is_lock_free</tt> only apply to individual objects
40462 is pretty useless
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.
40471 </p>
40472
40473 <p><i>[
40474 2009-06-16 Jeffrey Yasskin adds:
40475 ]</i></p>
40476
40477
40478 <blockquote>
40479 <p>
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.
40489 </p>
40490
40491 <p>
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>.
40497 </p>
40498 </blockquote>
40499
40500 <p><i>[
40501 2009-10-22 Benjamin Kosnik:
40502 ]</i></p>
40503
40504
40505 <blockquote>
40506 <p>
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
40510 </p>
40511
40512 <p>
40513 This is stated in the paper as:
40514 </p>
40515 <p>
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
40519 </p>
40520
40521 <p>
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.
40525 </p>
40526
40527 <p><i>[
40528 Howard: Put Benjamin's wording in the proposed wording section.
40529 ]</i></p>
40530
40531
40532 </blockquote>
40533
40534 <p><i>[
40535 2009-10-22 Alberto Ganesh Barbati:
40536 ]</i></p>
40537
40538
40539 <blockquote>
40540 <p>
40541 Just a thought... wouldn't it be better to use a scoped enum instead of
40542 plain integers? For example:
40543 </p>
40544
40545 <blockquote><pre>enum class is_lock_free
40546 {
40547     never = 0, sometimes = 1, always = 2;
40548 };
40549 </pre></blockquote>
40550
40551 <p>
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
40554 than 0, 1 and 2.
40555 </p>
40556
40557 </blockquote>
40558
40559 <p><i>[
40560 2009-10 Santa Cruz:
40561 ]</i></p>
40562
40563
40564 <blockquote>
40565 NAD Editorial.  Solved by
40566 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40567 </blockquote>
40568
40569
40570
40571 <p><b>Proposed resolution:</b></p>
40572 <p>
40573 Header <tt>&lt;cstdatomic&gt;</tt> synopsis  [atomics.synopsis]
40574 </p>
40575
40576 <p>
40577 Edit  as follows:
40578 </p>
40579
40580 <blockquote><pre>namespace std {
40581 ...
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>
40594
40595 <p>
40596 Lock-free Property 29.4 [atomics.lockfree]
40597 </p>
40598
40599 <p>
40600 Edit the synopsis as follows.
40601 </p>
40602
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
40614 }
40615 </pre></blockquote>
40616
40617 <p>
40618 Edit paragraph 1 as follows.
40619 </p>
40620
40621 <blockquote>
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>
40626 A value of 0
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.
40630 </blockquote>
40631
40632 <p>
40633 Operations on Atomic Types 29.6 [atomics.types.operations]
40634 </p>
40635
40636 <p>
40637 Edit as follows.
40638 </p>
40639
40640 <blockquote><pre><del>void</del> <ins>static constexpr bool</ins> A::is_lock_free() const volatile;
40641 </pre>
40642 <blockquote>
40643 <i>Returns:</i> True if the <del>object's</del> <ins>types's</ins> operations are lock-free, false
40644 otherwise.
40645 <ins>
40646 [<i>Note:</i> In the same way that <tt>&lt;limits&gt;</tt>
40647 <tt>std::numeric_limits&lt;short&gt;::max()</tt> is related to
40648 <tt>&lt;limits.h&gt;</tt> <tt>__LONG_LONG_MAX__</tt>, <tt>&lt;atomic&gt;
40649 std::atomic_short::is_lock_free</tt> is related to
40650 <tt>&lt;stdatomic.h&gt;</tt> and <tt>ATOMIC_SHORT_LOCK_FREE</tt> \97
40651 <i>end note</i>]
40652 </ins>
40653 </blockquote>
40654 </blockquote>
40655
40656
40657
40658
40659
40660
40661 <hr>
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>
40669
40670 <p><b>Addresses US 90</b></p>
40671
40672 <p>
40673 The C++0X draft
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),
40677 </p>
40678
40679 <blockquote>
40680 <p>
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 ]
40688 </p>
40689 </blockquote>
40690
40691 <p>
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.
40695 Here's why:
40696 </p>
40697
40698 <p>
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_&lt;op&gt;_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:
40712 </p>
40713
40714 <pre><code>class atomic_int {
40715   __atomic_int_storage value;
40716  public:
40717   int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
40718     // &amp;value has type "volatile __atomic_int_storage*".
40719     atomic_fetch_add_explicit(&amp;value, increment, order);
40720   }
40721   ...
40722 };
40723 </code></pre>
40724
40725 <p>
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,
40730 I'd need to write:
40731 </p>
40732
40733 <pre><code>class atomic_int {
40734   __atomic_int_storage value;
40735  public:
40736   int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
40737     atomic_fetch_add_explicit(&amp;value, increment, order);
40738   }
40739   int fetch_add(int increment, memory_order order = memory_order_seq_cst) {
40740     atomic_fetch_add_explicit(&amp;value, increment, order);
40741   }
40742   ...
40743 };
40744 </code></pre>
40745
40746 <p>
40747 But this is visibly different from the declarations in the standard
40748 because it's now overloaded.
40749 (Consider passing &amp;atomic_int::fetch_add as a template parameter.)
40750 </p>
40751
40752 <p>
40753 The implementation may already have permission to add overloads
40754 to the member functions:
40755 </p>
40756
40757 <blockquote>
40758 <p>
40759 17.6.4.5 [member.functions] An implementation may declare additional non-virtual
40760 member function signatures within a class:<br>
40761 ...
40762 </p>
40763 <ul>
40764 <li>by adding a member function signature for a member function name.</li>
40765 </ul>
40766 </blockquote>
40767
40768 <p>
40769 but I don't see an equivalent permission to add overloads to the free functions.
40770 </p>
40771
40772 <p><i>[
40773 2009-06-16 Lawrence adds:
40774 ]</i></p>
40775
40776
40777 <blockquote>
40778 <p>
40779 I recommend allowing non-volatile overloads.
40780 </p>
40781 </blockquote>
40782
40783 <p><i>[
40784 2009-10 Santa Cruz:
40785 ]</i></p>
40786
40787
40788 <blockquote>
40789 NAD Editorial.  Solved by
40790 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
40791 </blockquote>
40792
40793
40794
40795 <p><b>Proposed resolution:</b></p>
40796
40797
40798
40799
40800
40801 <hr>
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>
40809 <p>
40810 The header <tt>&lt;iomanip&gt;</tt> synopsis in 27.7 [iostream.format] specifies
40811 </p>
40812 <blockquote><pre>T5 setprecision(int n);
40813 T6 setw(int n);
40814 </pre></blockquote>
40815
40816 <p>
40817 The argument types should be streamsize, as in class <tt>ios_base</tt>
40818 (see 27.5.2 [ios.base]):
40819 </p>
40820 <blockquote><pre>streamsize precision() const;
40821 streamsize precision(streamsize prec);
40822 streamsize width() const;
40823 streamsize width(streamsize wide);
40824 </pre></blockquote>
40825
40826 <p>
40827 (Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
40828 </p>
40829
40830 <p><i>[
40831 2009-07-29 Daniel clarified wording.
40832 ]</i></p>
40833
40834
40835 <p><i>[
40836 2009 Santa Cruz:
40837 ]</i></p>
40838
40839
40840 <blockquote>
40841 <p>
40842 No concensus for this change.  There was some interest in doing the opposite
40843 fix:  Change the <tt>streamsize</tt> in <tt>&lt;ios&gt;</tt> to <tt>int</tt>.
40844 But ultimately there was no concensus for that change either.
40845 </p>
40846 </blockquote>
40847
40848
40849
40850 <p><b>Proposed resolution:</b></p>
40851 <ol>
40852 <li>
40853 <p>
40854 In 27.7 [iostream.format], header <tt>&lt;iomanip&gt;</tt> synopsis change as indicated:
40855 </p>
40856
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>
40860 </li>
40861
40862 <li>
40863 <p>
40864 In 27.7.3 [std.manip], just before p. 6 change as indicated:
40865 </p>
40866
40867 <blockquote><pre>unspecified setprecision(<del>int</del><ins>streamsize</ins> n);
40868 </pre></blockquote>
40869 </li>
40870
40871 <li>
40872 <p>
40873 In 27.7.3 [std.manip], just before p. 7 change as indicated:
40874 </p>
40875
40876 <blockquote><pre>unspecified setw(<del>int</del><ins>streamsize</ins> n);
40877 </pre></blockquote>
40878 </li>
40879 </ol>
40880
40881
40882
40883
40884
40885
40886
40887
40888 <hr>
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>
40894 <p>
40895 In X [rand.concept.urng], we have the following:
40896 </p>
40897 <blockquote><pre>concept UniformRandomNumberGenerator&lt;typename G&gt; : Callable&lt;G&gt; {
40898   ...
40899   axiom NonemptyRange(G&amp; g) {
40900     G::min() &lt; G::max();
40901   }
40902   ...
40903 }
40904 </pre></blockquote>
40905
40906 <p>
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:
40910 </p>
40911
40912 <blockquote><pre>axiom NonemptyRange()  {
40913   G::min() &lt; G::max();
40914 }
40915 </pre></blockquote>
40916
40917 <p>
40918 We can further reformulate so as to avoid any axiom machinery as:
40919 </p>
40920
40921 <blockquote><pre>requires True&lt; G::min() &lt; G::max() &gt;;
40922 </pre></blockquote>
40923
40924 <p>
40925 This is not only a simpler statement of the same requirement, but also
40926 forces the requirement to be checked.
40927 </p>
40928
40929 <p><i>[
40930 Post-Rapperswil:
40931 ]</i></p>
40932
40933
40934 <blockquote>
40935 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
40936 </blockquote>
40937
40938
40939 <p><b>Proposed resolution:</b></p>
40940 <p>
40941 In X [rand.concept.urng], replace the <tt>NonemptyRange</tt> axiom by:
40942 </p>
40943
40944 <blockquote><pre><del>axiom NonemptyRange(G&amp; g) { 
40945    G::min() &lt; G::max(); 
40946 }</del>
40947 <ins>requires True&lt; G::min() &lt; G::max() &gt;;</ins>
40948 </pre></blockquote>
40949
40950
40951
40952
40953
40954
40955 <hr>
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>
40962
40963    <p><b>Description</b></p>
40964         <p>It is a problem
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&amp;</tt>).</p>
40967 <p><b>Suggestion</b></p>
40968         <p>Add
40969         interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
40970
40971 <p><i>[
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.
40974 ]</i></p>
40975
40976
40977 <p><i>[
40978 2009-09-21 Daniel adds:
40979 ]</i></p>
40980
40981
40982 <blockquote>
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.
40986 </blockquote>
40987
40988 <p><i>[
40989 2009 Santa Cruz:
40990 ]</i></p>
40991
40992
40993 <blockquote>
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>.
40995 </blockquote>
40996
40997
40998
40999 <p><b>Proposed resolution:</b></p>
41000
41001
41002
41003
41004
41005 <hr>
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>
41014
41015 <p><b>Addresses DE 2</b></p>
41016
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>
41029
41030 <p><b>Notes</b></p>
41031         <p>Robert Klarer to address this one.</p>
41032
41033 <p><i>[
41034 2009 Santa Cruz:
41035 ]</i></p>
41036
41037
41038 <blockquote>
41039 Move to "Open". Robert Klarer has promised to provide wording.
41040 </blockquote>
41041
41042 <p><i>[
41043 2010 Pittsburgh:  Moved to NAD, rationale added below.
41044 ]</i></p>
41045
41046
41047
41048
41049 <p><b>Rationale:</b></p>
41050 <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.
41053 </p>
41054
41055
41056 <p><b>Proposed resolution:</b></p>
41057
41058
41059
41060
41061
41062 <hr>
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>
41069
41070 <p><b>Addresses FR 35</b></p>
41071
41072 <p><b>Description</b></p>
41073         <p>Instantiations of the class
41074         template <tt>complex&lt;&gt;</tt> have to be allowed for integral
41075         types, to reflect existing practice and ISO standards
41076         (LIA-III).</p>
41077         
41078 <p><b>Suggestion</b></p>
41079
41080 <p><i>[
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>.
41083 ]</i></p>
41084
41085
41086 <p><i>[
41087 2010 Pittsburgh:
41088 ]</i></p>
41089
41090
41091 <blockquote>
41092 Moved to NAD Future.  Rationale added.
41093 </blockquote>
41094
41095
41096
41097 <p><b>Rationale:</b></p>
41098 <p>
41099 There is no consensus for making this change at this time.
41100 </p>
41101
41102
41103 <p><b>Proposed resolution:</b></p>
41104 Adopt
41105 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3002.pdf">N3002</a>.
41106
41107
41108
41109
41110
41111 <hr>
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>
41118
41119 <p><b>Addresses FR 38</b></p>
41120
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 &lt;cstdint&gt; 
41135     18.4.1 [cstdint.syn]. Assign to C liasons.</p>
41136
41137 <p><i>[
41138 2009-10 Santa Cruz:
41139 ]</i></p>
41140
41141
41142 <blockquote>
41143 NAD Editorial. Already fixed.
41144 </blockquote>
41145
41146
41147
41148 <p><b>Proposed resolution:</b></p>
41149
41150
41151
41152
41153
41154 <hr>
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>
41160
41161 <p><b>Addresses UK 165</b></p>
41162
41163 <p><b>Description</b></p>
41164         <p>Constraints on
41165         bitmask and enumeration types were supposed to be tightened
41166         up as part of the motivation for the <tt>constexpr</tt> feature -
41167         see paper
41168         <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a>
41169         for details</p>
41170 <p><b>Suggestion</b></p>
41171         <p>Adopt wording in line with the motivation
41172         described in
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>
41176
41177 <p><i>[
41178 2009 Santa Cruz:
41179 ]</i></p>
41180
41181
41182 <blockquote>
41183 Move to Open. Ping Robert Klarer to provide wording, using N2235 as
41184 guidance.
41185 </blockquote>
41186
41187 <p><i>[
41188 2010 Pittsburgh:
41189 ]</i></p>
41190
41191
41192 <blockquote>
41193 Moved to NAD.  Rationale added.
41194 </blockquote>
41195
41196
41197
41198 <p><b>Rationale:</b></p>
41199 <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.
41203 </p>
41204
41205
41206 <p><b>Proposed resolution:</b></p>
41207
41208
41209
41210
41211
41212 <hr>
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>
41218
41219 <p><b>Addresses UK 331</b></p>
41220
41221 <p><b>Description</b></p>
41222         <p>Not clear what
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 
41234     sense.</p>
41235
41236 <p><i>[
41237 2009-07 Frankfurt
41238 ]</i></p>
41239
41240
41241 <blockquote>
41242 Pending a paper from Anthony Williams / Detleff Volleman.
41243 </blockquote>
41244
41245 <p><i>[
41246 2009-10-14 Pending paper:
41247 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41248 ]</i></p>
41249
41250
41251 <p><i>[
41252 2009-10 Santa Cruz:
41253 ]</i></p>
41254
41255
41256 <blockquote>
41257 NAD Editorial.  Solved by
41258 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41259 </blockquote>
41260
41261
41262
41263 <p><b>Proposed resolution:</b></p>
41264
41265
41266
41267
41268
41269 <hr>
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>
41276
41277 <p><b>Addresses UK 336</b></p>
41278
41279 <p><b>Description</b></p>
41280
41281         <p>It is possible
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>
41298
41299 <p><i>[
41300 2009-07 Frankfurt
41301 ]</i></p>
41302
41303
41304 <blockquote>
41305 Pending a paper from Anthony Williams / Detleff Volleman.
41306 </blockquote>
41307
41308 <p><i>[
41309 2009-10-14 Pending paper:
41310 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41311 ]</i></p>
41312
41313
41314 <p><i>[
41315 2009-10 Santa Cruz:
41316 ]</i></p>
41317
41318
41319 <blockquote>
41320 NAD Editorial.  Solved by
41321 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41322 </blockquote>
41323
41324
41325
41326 <p><b>Proposed resolution:</b></p>
41327
41328
41329
41330
41331
41332 <hr>
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>
41339
41340 <p><b>Addresses UK 337</b></p>
41341
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>
41351
41352 <p><i>[
41353 2009-07 Frankfurt
41354 ]</i></p>
41355
41356
41357 <blockquote>
41358 Pending a paper from Anthony Williams / Detleff Volleman.
41359 </blockquote>
41360
41361 <p><i>[
41362 2009-10-14 Pending paper:
41363 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41364 ]</i></p>
41365
41366
41367 <p><i>[
41368 2009-10 Santa Cruz:
41369 ]</i></p>
41370
41371
41372 <blockquote>
41373 NAD Editorial.  Solved by
41374 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41375 </blockquote>
41376
41377
41378
41379 <p><b>Proposed resolution:</b></p>
41380
41381
41382
41383
41384
41385 <hr>
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>
41392
41393 <p><b>Addresses UK 338</b></p>
41394
41395 <p><b>Description</b></p>
41396
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&amp;&amp;
41412         rhs)</tt>, and a move-assignment operator <tt>shared_future&amp;
41413         operator=(shared_future&amp;&amp; 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
41419         state.</p>
41420 <p><b>Notes</b></p>
41421 <p>Create an issue. Detlef will look into it.</p>
41422
41423 <p><i>[
41424 2009-07 Frankfurt
41425 ]</i></p>
41426
41427
41428 <blockquote>
41429 Pending a paper from Anthony Williams / Detleff Volleman.
41430 </blockquote>
41431
41432 <p><i>[
41433 2009-10-14 Pending paper:
41434 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
41435 ]</i></p>
41436
41437
41438 <p><i>[
41439 2009-10 Santa Cruz:
41440 ]</i></p>
41441
41442
41443 <blockquote>
41444 NAD Editorial.  Solved by
41445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.htm">N2997</a>.
41446 </blockquote>
41447
41448
41449
41450 <p><b>Proposed resolution:</b></p>
41451
41452
41453
41454
41455
41456 <hr>
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>
41464
41465 <p><b>Addresses UK 341</b></p>
41466
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>
41471
41472 <p><b>Suggestion</b></p>
41473 <p>Change <tt>promise::swap</tt> to take an rvalue reference.</p>
41474
41475 <p><b>Notes</b></p>
41476 <p>Create an issue. Detlef will look into it. Probably ready as it.</p>  
41477
41478 <p><i>[
41479 2009-07 Frankfurt
41480 ]</i></p>
41481
41482
41483 <blockquote>
41484 NAD, by virtue of the changed rvalue rules and swap signatures from Summit.
41485 </blockquote>
41486
41487
41488
41489 <p><b>Proposed resolution:</b></p>
41490
41491
41492
41493
41494
41495 <hr>
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>
41503
41504 <p><b>Addresses UK 343</b></p>
41505
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>
41512         <p>Remove the
41513         constructor with the signature <tt>template &lt;class
41514         Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
41515         a, promise&amp; 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>
41519
41520 <p><i>[
41521 2009-07 Frankfurt
41522 ]</i></p>
41523
41524
41525 <blockquote>
41526 Pending a paper from Anthony Williams / Detleff Volleman.
41527 </blockquote>
41528
41529 <p><i>[
41530 2009-10 Santa Cruz:
41531 ]</i></p>
41532
41533
41534 <blockquote>
41535 NAD Editorial.  Solved by
41536 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
41537 </blockquote>
41538
41539
41540
41541 <p><b>Proposed resolution:</b></p>
41542
41543
41544
41545
41546
41547 <hr>
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>
41554
41555 <p><b>Addresses US 77</b></p>
41556
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
41565         paper.</p>
41566         <p>With the
41567         introduction of rvalue references, we are teaching
41568         programmers that moving from a standard container (e.g., a
41569         <tt>vector&lt;string&gt;</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>
41577
41578         <p>Remove 20.8.4.</p>
41579         
41580         <p>Remove 20.8.5.</p>
41581         
41582         <p>Remove all references to the facilities in
41583         20.8.4 and 20.8.5 from clause 23.</p>
41584
41585
41586 <p><i>[
41587 2009-10 Santa Cruz:
41588 ]</i></p>
41589
41590
41591 <blockquote>
41592 NAD Editorial.  Addressed by
41593 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
41594 </blockquote>
41595
41596
41597
41598 <p><b>Proposed resolution:</b></p>
41599
41600
41601
41602
41603
41604 <hr>
41605 <h3><a name="1167"></a>1167. <tt>pair&lt;T,U&gt;</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>
41612 <p>
41613 <tt>LessThanComparable</tt> requires (and provides default
41614              implementations for) &lt;=,&gt;, and &gt;=.  However, the defaults
41615              don't take effect in unconstrained code.
41616 </p>
41617 <p>
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.
41622 </p>
41623 <p>
41624 Totally Unbiased
41625 Suggested Resolution:
41626 </p>
41627 <p>
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
41631                     function templates
41632 </p>
41633 <p>
41634 e.g., remove from the body of <tt>std::list</tt>
41635 </p>
41636 <blockquote><pre>template &lt;LessThanComparable T, class Allocator&gt; 
41637 bool operator&lt; (const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
41638 template &lt;LessThanComparable T, class Allocator&gt; 
41639 bool operator&gt; (const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
41640 template &lt;LessThanComparable T, class Allocator&gt; 
41641 bool operator&gt;=(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
41642 template &lt;LessThanComparable T, class Allocator&gt; 
41643 bool operator&lt;=(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
41644 </pre></blockquote>
41645 <p>
41646 and add this concept_map afterwards:
41647 </p>
41648 <blockquote><pre>template &lt;LessThanComparable T, class Allocator&gt; 
41649 export concept_map LessThanComparable&lt;list&lt;T,Allocator&gt; &gt;
41650 {
41651     bool operator&lt;(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y);
41652 }
41653 </pre></blockquote>
41654 <p>
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.
41657 </p>
41658 <p>
41659 Alternative Resolution: keep the ugly, complex specification and add the
41660                        missing operators to <tt>std::pair</tt>.
41661 </p>
41662
41663
41664 <p><b>Proposed resolution:</b></p>
41665
41666
41667
41668
41669
41670 <hr>
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>
41677 <p>
41678 The following wording seems a little unusual to me:
41679 </p>
41680 <p>
41681 p42/43 20.5.2 [bitset.members]
41682 </p>
41683
41684 <blockquote>
41685 <pre>bool operator==(const bitset&lt;N&gt;&amp; rhs) const;
41686 </pre>
41687 <blockquote>
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
41690 <tt>rhs</tt>.
41691 </blockquote>
41692 <pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
41693 </pre>
41694 <blockquote>
41695 -43- <i>Returns:</i> A nonzero value if <tt>!(*this == rhs)</tt>.
41696 </blockquote>
41697 </blockquote>
41698
41699 <p>
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.
41703 </p>
41704
41705 <p><i>[
41706 2009-07-24 Alisdair recommends NAD Editorial.
41707 ]</i></p>
41708
41709
41710 <p><i>[
41711 2009-07-27 Pete adds:
41712 ]</i></p>
41713
41714
41715 <blockquote>
41716 It's obviously editorial. There's no need for further discussion.
41717 </blockquote>
41718
41719 <p><i>[
41720 2009-07-27 Howard sets to NAD Editorial.
41721 ]</i></p>
41722
41723
41724
41725
41726 <p><b>Proposed resolution:</b></p>
41727 <p>
41728 Change 20.5.2 [bitset.members] p42-43:
41729 </p>
41730
41731 <blockquote>
41732 <pre>bool operator==(const bitset&lt;N&gt;&amp; rhs) const;
41733 </pre>
41734 <blockquote>
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
41737 <tt>rhs</tt>.
41738 </blockquote>
41739 <pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
41740 </pre>
41741 <blockquote>
41742 -43- <i>Returns:</i> <del>A nonzero value</del> <ins><tt>true</tt></ins> if <tt>!(*this == rhs)</tt>.
41743 </blockquote>
41744 </blockquote>
41745
41746
41747
41748
41749
41750
41751 <hr>
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>
41757 <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):
41762 </p>
41763 <blockquote>
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>.
41766 </blockquote>
41767 <p>
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.
41776 </p>
41777 <p>
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.
41780 </p>
41781
41782 <p><i>[
41783 2009-10 Santa Cruz:
41784 ]</i></p>
41785
41786
41787 <blockquote>
41788 NAD Editorial.  Addressed by
41789 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
41790 </blockquote>
41791
41792
41793
41794 <p><b>Proposed resolution:</b></p>
41795 <p>
41796 Replace X [allocator.concepts.members]/21 with:
41797 </p>
41798
41799 <blockquote><pre>X select_on_container_copy_construction(const X&amp; x);
41800 </pre>
41801 <p>
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>
41809 </p>
41810 </blockquote>
41811
41812 <p>
41813 Replace X [allocator.concepts.members]/25 with:
41814 </p>
41815
41816 <blockquote><pre>X select_on_container_move_construction(X&amp;&amp; x);
41817 </pre>
41818 <p>
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>
41826 </p>
41827 </blockquote>
41828
41829
41830
41831
41832
41833
41834 <hr>
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>
41842 <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
41845 defined.
41846 </p>
41847 <p>
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
41850 the instances.
41851 </p>
41852 <p>
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.
41857 </p>
41858 <p>
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 ==.
41862 </p>
41863
41864 <p><i>[
41865 2009 Santa Cruz:
41866 ]</i></p>
41867
41868
41869 <blockquote>
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.
41874 </blockquote>
41875
41876
41877 <p><i>[
41878 2010 Rapperswil:
41879 ]</i></p>
41880
41881
41882 <blockquote>
41883 This issue is quite vague, so it is difficult to know if and when it has been resolved.
41884
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.
41886
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.
41888
41889 Move to Tentatively NAD Future.
41890 </blockquote>
41891
41892 <p><i>[
41893 Moved to NAD Future at 2010-11 Batavia
41894 ]</i></p>
41895
41896
41897
41898
41899 <p><b>Proposed resolution:</b></p>
41900
41901
41902
41903
41904
41905 <hr>
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>
41912 <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.
41916 </p>
41917
41918 <blockquote><pre>template &lt;class F<del>, class ...Args</del>&gt; thread(F&amp;&amp; f<del>, Args&amp;&amp;... args</del>);
41919 </pre></blockquote>
41920
41921 <p>
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.
41924 </p>
41925
41926 <p><i>[
41927 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
41928 Rationale added below.
41929 ]</i></p>
41930
41931
41932
41933 <p><b>Proposed resolution:</b></p>
41934 <p>
41935 </p>
41936
41937
41938 <p><b>Rationale:</b></p>
41939 <p>
41940 The (tentative) concensus of the LWG is to keep the variadic thread constructor.
41941 </p>
41942
41943
41944
41945
41946
41947 <hr>
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>
41954 <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:
41956 </p>
41957
41958 <blockquote>
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).
41963 </blockquote>
41964
41965 <p>
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.
41969 </p>
41970
41971 <p><i>[
41972 2009-07-21 Chris adds:
41973 ]</i></p>
41974
41975
41976 <blockquote>
41977 <p>
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
41981 example:
41982 </p>
41983
41984 <blockquote><pre>void foobar(error_code&amp; ec = throws());
41985 </pre></blockquote>
41986
41987 <p>
41988  Error conditions:
41989 </p>
41990 <blockquote>
41991 permission_denied - Insufficient privilege to perform operation.
41992 </blockquote>
41993
41994 <p>
41995 When a user writes:
41996 </p>
41997
41998 <blockquote><pre>error_code ec;
41999 foobar(ec);
42000 if (ec == errc::permission_denied)
42001    ...
42002 </pre></blockquote>
42003
42004 <p>
42005 the implicit conversion <tt>errc-&gt;error_condition</tt> makes the if-test
42006 equivalent to:
42007 </p>
42008
42009 <blockquote><pre>if (ec == make_error_condition(errc::permission_denied))
42010 </pre></blockquote>
42011
42012 <p>
42013 On the other hand, if the user had written:
42014 </p>
42015
42016 <blockquote><pre>if (ec == make_error_code(errc::permission_denied))
42017 </pre></blockquote>
42018
42019 <p>
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".
42023 </p>
42024 </blockquote>
42025
42026 <p><i>[
42027 2009 Santa Cruz:
42028 ]</i></p>
42029
42030
42031 <blockquote>
42032 <p>
42033 NAD Editorial.
42034 </p>
42035 <p>
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.
42042 </p>
42043 </blockquote>
42044
42045
42046
42047 <p><b>Proposed resolution:</b></p>
42048 <p>
42049 </p>
42050
42051
42052
42053
42054
42055 <hr>
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>
42062 <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.
42065 </p>
42066
42067 <p><i>[
42068 2009-10 Santa Cruz:
42069 ]</i></p>
42070
42071
42072 <blockquote>
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.
42075 </blockquote>
42076
42077
42078
42079 <p><b>Proposed resolution:</b></p>
42080
42081
42082
42083
42084
42085 <hr>
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>
42092 <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)
42096 </p>
42097
42098 <p>
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:
42102 </p>
42103
42104 <blockquote>
42105 XXX iterators satisfy all the requirements of the input and output iterators
42106 and can be used whenever either kind is specified ...
42107 </blockquote>
42108
42109 <p>
42110 Meanwhile, p4 goes on to contradict this:
42111 </p>
42112
42113 <blockquote>
42114 Besides its category, a forward, bidirectional, or random access
42115 iterator can also be mutable or constant...
42116 </blockquote>
42117
42118 <blockquote>
42119 ... Constant iterators do not satisfy the requirements for output iterators
42120 </blockquote>
42121
42122 <p>
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>.
42126 </p>
42127
42128 <p>
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 -&gt; forward -&gt; bidirectional -&gt;
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.
42135 </p>
42136
42137 <p><i>[
42138 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
42139 ]</i></p>
42140
42141
42142
42143
42144 <p><b>Rationale:</b></p>
42145 <p>
42146 Solved by
42147 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
42148 </p>
42149
42150
42151 <p><b>Proposed resolution:</b></p>
42152
42153
42154
42155
42156
42157 <hr>
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>
42163 <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
42167 this.
42168 </p>
42169
42170 <p>
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>&lt;forward_list&gt;</tt> header and then
42175 everything just works, including a user's own further uses in a
42176 stack-like context.
42177 </p>
42178
42179 <p>
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
42184 library.
42185 </p>
42186
42187 <p><i>[
42188 2009-11-02 Howard adds:
42189 ]</i></p>
42190
42191
42192 <blockquote>
42193 Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
42194 </blockquote>
42195
42196
42197 <p><b>Rationale:</b></p>
42198 <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
42201 library.
42202 </p>
42203
42204
42205
42206 <p><b>Proposed resolution:</b></p>
42207
42208
42209
42210
42211
42212 <hr>
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>
42220 <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
42226 increases.
42227 </p>
42228
42229 <p>
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
42241 factor.)
42242 </p>
42243
42244 <p>
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.
42250 </p>
42251
42252 <p>
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.)
42258 </p>
42259
42260 <p>
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.
42264 </p>
42265
42266
42267 <p><i>[
42268 2010 Rapperswil:
42269 ]</i></p>
42270
42271
42272 <blockquote>
42273 This seems to a useful extension, but is too late for 0x.
42274
42275 Move to Tentatively NAD Future.
42276 </blockquote>
42277
42278 <p><i>[
42279 Moved to NAD Future at 2010-11 Batavia
42280 ]</i></p>
42281
42282
42283
42284
42285 <p><b>Proposed resolution:</b></p>
42286 <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]:
42289 </p>
42290
42291 <blockquote>
42292 <table border="1">
42293 <caption>Table 87 \97 Unordered associative container requirements
42294 (in addition to container)</caption>
42295
42296 <tbody><tr>
42297 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
42298 <th>Complexity</th>
42299 </tr>
42300 <tr>
42301 <td><ins>
42302 <tt>a.min_load_factor()</tt>
42303 </ins></td>
42304 <td><ins>
42305 <tt>float</tt>
42306 </ins></td>
42307 <td><ins>
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
42311 above this number.
42312 </ins></td>
42313 <td><ins>
42314 constant
42315 </ins></td>
42316 </tr>
42317
42318 <tr>
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.]
42325 </ins></td>
42326 <td><ins>
42327 constant
42328 </ins></td>
42329 </tr>
42330 <tr>
42331 <td><tt>a.rehash(n)</tt></td>
42332 <td><tt>void</tt></td>
42333 <td>
42334 Post: <ins><tt>a.bucket_count() &gt;= n</tt>, and <tt>a.size() &lt;= 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>
42340 <del>
42341 <tt>a.bucket_cout &gt; a.size() / a.max_load_factor()</tt> and <tt>a.bucket_count()
42342 &gt;= n</tt>.
42343 </del>
42344 </td>
42345 <td>
42346 Average case linear in <tt>a.size()</tt>, worst case quadratic.
42347 </td>
42348 </tr>
42349 </tbody></table>
42350 </blockquote>
42351
42352 <p>
42353 Add a footnote to 23.2.5 [unord.req] p12:
42354 </p>
42355
42356 <blockquote>
42357 <p>
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
42361 erased elements.
42362 </p>
42363
42364 <blockquote><ins>
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>
42369 </blockquote>
42370
42371 <p>
42372 Change paragraph 13:
42373 </p>
42374
42375 <blockquote>
42376 The insert members shall not affect the validity of iterators if
42377 <del><tt>(N+n) &lt; z * B</tt></del> <ins><tt>zmin * B &lt;= (N+n) &lt;= 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.
42383 </blockquote>
42384
42385 <p>
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]:
42391 </p>
42392
42393 <blockquote><pre><ins>
42394 float min_load_factor() const;
42395 void min_load_factor(float z);
42396 </ins></pre></blockquote>
42397
42398 <p>
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:
42401 </p>
42402
42403 <blockquote>
42404 ... <tt>max_load_factor()</tt> returns 1.0 <ins>and
42405 <tt>min_load_factor()</tt> returns 0</ins>.
42406 </blockquote>
42407
42408
42409
42410
42411
42412 <hr>
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>
42420 <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.
42425 </p>
42426
42427
42428 <p><i>[
42429 2010 Rapperswil:
42430 ]</i></p>
42431
42432
42433 <blockquote>
42434 The benefit seems minor, while breaking with the getter/setter idiom these overloads support.
42435
42436 Move to Tentatively NAD.
42437 </blockquote>
42438
42439 <p><i>[
42440 Moved to NAD at 2010-11 Batavia
42441 ]</i></p>
42442
42443
42444
42445
42446 <p><b>Proposed resolution:</b></p>
42447 <p>
42448 In the unordered associative container requirements table, change:
42449 </p>
42450
42451 <blockquote>
42452 <table border="1">
42453 <caption>Table 87 \97 Unordered associative container requirements
42454 (in addition to container)</caption>
42455
42456 <tbody><tr>
42457 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
42458 <th>Complexity</th>
42459 </tr>
42460
42461 <tr>
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>
42468 </td>
42469 <td>
42470 constant
42471 </td>
42472 </tr>
42473 <tr></tr>
42474 </tbody></table>
42475 </blockquote>
42476
42477 <p>
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].
42481 </p>
42482
42483 <p>
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>.
42486 </p>
42487
42488
42489
42490
42491
42492 <hr>
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>
42498 <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.
42504 </p>
42505
42506 <p><i>[
42507 2009-08-23 Daniel adds:
42508 ]</i></p>
42509
42510
42511 <blockquote>
42512 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a> provides wording that solves this issue.
42513 </blockquote>
42514
42515 <p><i>[
42516 2009-10 Santa Cruz:
42517 ]</i></p>
42518
42519
42520 <blockquote>
42521 Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>.
42522 </blockquote>
42523
42524
42525
42526 <p><b>Proposed resolution:</b></p>
42527
42528
42529
42530
42531
42532 <hr>
42533 <h3><a name="1200"></a>1200. "surprising" <tt>char_traits&lt;T&gt;::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>
42539 <p>
42540 The footnote for <tt>int_type</tt> in 21.2.2 [char.traits.typedefs] says that
42541 </p>
42542
42543 <blockquote>
42544 If <tt>eof()</tt>
42545 can be held in <tt>char_type</tt> then some iostreams implementations may give
42546 surprising results.
42547 </blockquote>
42548
42549 <p>
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.
42558 </p>
42559
42560 <p>
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
42569 types.
42570 </p>
42571
42572 <p><i>[
42573 2009-10-28 Ganesh provides two possible resolutions and expresses a preference
42574 for the second:
42575 ]</i></p>
42576
42577
42578 <blockquote>
42579 <ol>
42580 <li>
42581 <p>
42582 Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
42583 </p>
42584
42585 <blockquote>
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
42591 note</i>]</ins>.
42592 </blockquote>
42593
42594 <p>
42595 Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
42596 </p>
42597
42598 <blockquote>
42599 The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
42600 cannot appear as a Unicode code point</del>
42601 <ins>
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
42605 note</i>]</ins>.
42606 </blockquote>
42607 </li>
42608 <li>
42609 <p>
42610 In 21.2.3.2 [char.traits.specializations.char16_t], in the
42611 definition of <tt>char_traits&lt;char16_t&gt;</tt> replace the definition of nested
42612 typedef <tt>int_type</tt> with:
42613 </p>
42614
42615 <blockquote><pre>namespace std {
42616   template&lt;&gt; struct char_traits&lt;char16_t&gt; {
42617     typedef char16_t         char_type;
42618     typedef <del>uint_least16_t</del> <ins>uint_fast16_t</ins> int_type;
42619      ...
42620 </pre></blockquote>
42621
42622 <p>
42623 Replace 21.2.3.2 [char.traits.specializations.char16_t] para 3 with:
42624 </p>
42625
42626 <blockquote>
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
42632 note</i>]</ins>.
42633 </blockquote>
42634
42635 <p>
42636 In 21.2.3.3 [char.traits.specializations.char32_t], in the
42637 definition of <tt>char_traits&lt;char32_t&gt;</tt> replace the definition of nested
42638 typedef <tt>int_type</tt> with:
42639 </p>
42640
42641 <blockquote><pre>namespace std {
42642   template&lt;&gt; struct char_traits&lt;char32_t&gt; {
42643     typedef char32_t         char_type;
42644     typedef <del>uint_least32_t</del> <ins>uint_fast32_t</ins> int_type;
42645      ...
42646 </pre></blockquote>
42647
42648 <p>
42649 Replace 21.2.3.3 [char.traits.specializations.char32_t] para 3 with:
42650 </p>
42651
42652 <blockquote>
42653 The member <tt>eof()</tt> shall return <del>an implementation-defined constant that
42654 cannot appear as a Unicode code point</del>
42655 <ins>
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
42659 note</i>]</ins>.
42660 </blockquote>
42661 </li>
42662 </ol>
42663 </blockquote>
42664
42665
42666 <p><i>[
42667 2010 Rapperswil:
42668 ]</i></p>
42669
42670
42671 <blockquote>
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.
42673
42674 Move to Tentatively NAD.
42675 </blockquote>
42676
42677 <p><i>[
42678 Moved to NAD at 2010-11 Batavia
42679 ]</i></p>
42680
42681
42682
42683
42684 <p><b>Proposed resolution:</b></p>
42685 <p>
42686 </p>
42687
42688
42689
42690
42691
42692 <hr>
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>
42699 <p>
42700 Spotting a recent thread on the boost lists regarding collapsing
42701 optional representations in <tt>optional&lt;optional&lt;T&gt;&gt;</tt> instances, I wonder if
42702 we have some of the same issues with <tt>make_tuple</tt>, and now <tt>make_pair</tt>?
42703 </p>
42704
42705 <p>
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.
42710 </p>
42711
42712 <p>
42713 There are two things as a library author I can do at this point:
42714 </p>
42715
42716 <ol type="i">
42717 <li>
42718 document my library also has the same reference-wrapper behaviour as
42719 <tt>std::make_tuple</tt>
42720 </li>
42721 <li>
42722 roll my own <tt>make_tuple</tt> that does not unwrap rereferences, a lost
42723 opportunity to re-use the standard library.
42724 </li>
42725 </ol>
42726
42727 <p>
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>.)
42731 </p>
42732
42733 <p>
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>.
42739 </p>
42740
42741 <p><i>[
42742 2009-09-30 Daniel adds:
42743 ]</i></p>
42744
42745
42746 <blockquote>
42747 <p>
42748 I suggest to change the currently proposed paragraph for
42749 <tt>make_simple_pair</tt>
42750 </p>
42751
42752 <blockquote><pre>template&lt;typename... Types&gt;
42753   pair&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_pair(Types&amp;&amp;... t);
42754 </pre>
42755 <blockquote>
42756 <p>
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>
42760 </p>
42761 <p>
42762 ...
42763 </p>
42764 </blockquote>
42765 </blockquote>
42766
42767 <p>
42768 or alternatively (but with a slightly different semantic):
42769 </p>
42770
42771 <blockquote>
42772 <blockquote>
42773 <i>Remarks:</i> If <tt>sizeof...(Types) != 2</tt>, this function shall not
42774 participate in overload resolution.
42775 </blockquote>
42776 </blockquote>
42777
42778 <p>
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:
42785 </p>
42786
42787 <ol type="A">
42788 <li>
42789 <pre>template&lt;class T1, class T2&gt;
42790 pair&lt;typename decay&lt;T1&gt;::type, typename decay&lt;T2&gt;::type&gt;
42791 make_simple_pair(T1&amp;&amp; t1, T2&amp;&amp; t2);
42792 </pre>
42793 </li>
42794 <li>
42795 <pre>template&lt;class T1, class T2&gt;
42796 pair&lt;V1, V2&gt; make_simple_pair(T1&amp;&amp; t1, T2&amp;&amp; t2);
42797 </pre>
42798 <blockquote>
42799 Let <tt>V1</tt> be <tt>typename decay&lt;T1&gt;::type</tt> and <tt>V2</tt> be
42800 <tt>typename decay&lt;T2&gt;::type</tt>.
42801 </blockquote>
42802 </li>
42803 </ol>
42804
42805 </blockquote>
42806
42807 <p><i>[
42808 2009-10 post-Santa Cruz:
42809 ]</i></p>
42810
42811
42812 <blockquote>
42813 Mark as Tentatively NAD Future.
42814 </blockquote>
42815
42816
42817
42818 <p><b>Rationale:</b></p>
42819 <p>
42820 Does not have sufficient support at this time. May wish to reconsider for a
42821 future standard.
42822 </p>
42823
42824
42825 <p><b>Proposed resolution:</b></p>
42826 <p>
42827 Add the following function to 20.3.5 [pairs] and signature in
42828 appropriate synopses:
42829 </p>
42830
42831 <blockquote><pre>template&lt;typename... Types&gt;
42832   pair&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_pair(Types&amp;&amp;... t);
42833 </pre>
42834 <blockquote>
42835 <p>
42836 <i>Type requirements:</i> <tt>sizeof...(Types) == 2</tt>.
42837 </p>
42838 <p>
42839 <i>Returns:</i> <tt>pair&lt;typename decay&lt;Types&gt;::type...&gt;(std::forward&lt;Types&gt;(t)...)</tt>.
42840 </p>
42841 </blockquote>
42842 </blockquote>
42843
42844 <p><i>[
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
42850 ]</i></p>
42851
42852
42853 <p>
42854 Add the following function to 20.4.2.4 [tuple.creation] and
42855 signature in appropriate synopses:
42856 </p>
42857
42858 <blockquote><pre>template&lt;typename... Types&gt;
42859   tuple&lt;typename decay&lt;Types&gt;::type...&gt; make_simple_tuple(Types&amp;&amp;... t);
42860 </pre>
42861 <blockquote>
42862 <p>
42863 <i>Returns:</i> <tt>tuple&lt;typename decay&lt;Types&gt;::type...&gt;(std::forward&lt;Types&gt;(t)...)</tt>.
42864 </p>
42865 </blockquote>
42866 </blockquote>
42867
42868
42869
42870
42871
42872 <hr>
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>
42879 <p>
42880 The specification of <tt>integral_constant</tt> has been inherited
42881 essentially unchanged from TR1:
42882 </p>
42883
42884 <blockquote><pre>template &lt;class T, T v&gt;
42885 struct integral_constant {
42886   static const T value = v;
42887   typedef T value_type;
42888   typedef integral_constant&lt;T,v&gt; type;
42889 };
42890 </pre></blockquote>
42891
42892 <p>
42893 In light of 0x language changes there are several things we might
42894 consider changing, notably the form of specification for value.
42895 </p>
42896
42897 <p>
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
42900 syntax:
42901 </p>
42902
42903 <blockquote><pre>template &lt;class T, T v&gt;
42904 struct integral_constant {
42905   <b>enum : T { value = v };</b>
42906   typedef T value_type;
42907   typedef integral_constant type;
42908 };
42909 </pre></blockquote>
42910
42911 <p>
42912 The effective difference between these two implementation is:
42913 </p>
42914
42915 <ol type="i">
42916 <li>
42917 No requirement to allocate storage for data member (which we hope but do
42918 not guarantee compilers strip today)
42919 </li>
42920
42921 <li>
42922 You can no longer take the address of the constant as
42923 <tt>&amp;integral_constant&lt;T,v&gt;::value;</tt>
42924 </li>
42925 </ol>
42926
42927 <p>
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
42931 metaprogram.
42932 </p>
42933
42934 <p>
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.
42937 </p>
42938
42939 <p>
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>:
42943 </p>
42944
42945 <blockquote><pre>template &lt;class T, T v&gt;
42946 struct integral_constant {
42947   static <b>constexpr</b> T value = v;
42948   typedef T value_type;
42949   typedef integral_constant type;
42950 };
42951 </pre></blockquote>
42952
42953 <p>
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
42957 should be allowed.
42958 </p>
42959
42960 <p><i>[
42961 2009-09-05 Daniel adds:
42962 ]</i></p>
42963
42964
42965 <blockquote>
42966 <p>
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:
42973 </p>
42974
42975 <blockquote><pre>enum NodeColor { Red, Black };
42976
42977 std::integral_constant&lt;NodeColor, Red&gt; red;
42978 </pre></blockquote>
42979
42980 <p>
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.
42984 </p>
42985
42986 <p>
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.
42994 </p>
42995
42996 <p>
42997 Another possible disadvantage seems to me that user-expectations
42998 are easy to disappoint if they see a failure
42999 of the test
43000 </p>
43001
43002 <blockquote><pre>assert(typeid(std::integral_constant&lt;int, 0&gt;::value) == typeid(int));
43003 </pre></blockquote>
43004
43005 <p>
43006 or of
43007 </p>
43008
43009 <blockquote><pre>static_assert(std::is_same&lt;decltype(std::integral_constant&lt;int, 0&gt;::value), const int&gt;::value, "Bad library");
43010 </pre></blockquote>
43011
43012 </blockquote>
43013
43014 <p><i>[
43015 2010-01-14 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
43016 ]</i></p>
43017
43018
43019
43020
43021 <p><b>Rationale:</b></p>
43022 <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).
43025 </p>
43026
43027
43028 <p><b>Proposed resolution:</b></p>
43029
43030
43031
43032
43033
43034 <hr>
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>
43040 <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:
43043 </p>
43044
43045 <blockquote><pre>template &lt;class charT, class traits, class T&gt;
43046   basic_ostream&lt;charT, traits&gt;&amp;
43047   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os, const T&amp; x);
43048 </pre>
43049 <blockquote>
43050 <p>
43051 1 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
43052 </p>
43053 <p>
43054 2 <i>Returns:</i> <tt>os</tt>
43055 </p>
43056 </blockquote>
43057 </blockquote>
43058
43059 <p>
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:
43062 </p>
43063
43064 <blockquote><pre>std::ofstream("log file") &lt;&lt; "Some message\n";
43065 </pre></blockquote>
43066
43067 <p>
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:
43071 </p>
43072
43073 <blockquote><pre>std::string s = static_cast&lt;std::ostringstream&amp;&gt;(std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
43074 </pre></blockquote>
43075
43076 <p>
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&amp;</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
43081 insertion process.
43082 </p>
43083
43084 <p>
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:
43087 </p>
43088
43089 <blockquote><pre>std::string s = (std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
43090 </pre></blockquote>
43091
43092 <p>
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>.
43097 </p>
43098
43099 <p>
43100 The same argument and solution also applies to the inserter.  This code has been
43101 implemented and tested.
43102 </p>
43103
43104 <p><i>[
43105 2009 Santa Cruz:
43106 ]</i></p>
43107
43108
43109 <blockquote>
43110 NAD Future.  No concensus for change.
43111 </blockquote>
43112
43113
43114
43115 <p><b>Proposed resolution:</b></p>
43116 <p>
43117 Change 27.7.1.6 [istream.rvalue]:
43118 </p>
43119
43120 <blockquote><pre>template &lt;class <del>charT, class traits</del> <ins>Istream</ins>, class T&gt;
43121   <del>basic_istream&lt;charT, traits&gt;&amp;</del> <ins>Istream&amp;&amp;</ins>
43122   operator&gt;&gt;(<del>basic_istream&lt;charT, traits&gt;</del> <ins>Istream</ins>&amp;&amp; is, T&amp; x);
43123 </pre>
43124 <blockquote>
43125 <p>
43126 1 <i>Effects:</i> <tt>is &gt;&gt; x</tt>
43127 </p>
43128 <p>
43129 2 <i>Returns:</i> <tt><ins>std::move(</ins>is<ins>)</ins></tt>
43130 </p>
43131 <p><ins>
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
43134 <tt>ios_base</tt>.
43135 </ins></p>
43136 </blockquote>
43137 </blockquote>
43138
43139 <p>
43140 Change 27.7.2.9 [ostream.rvalue]:
43141 </p>
43142
43143 <blockquote><pre>template &lt;class <del>charT, class traits</del> <ins>Ostream</ins>, class T&gt;
43144   <del>basic_ostream&lt;charT, traits&gt;&amp;</del> <ins>Ostream&amp;&amp;</ins>
43145   operator&lt;&lt;(<del>basic_ostream&lt;charT, traits&gt;</del> <ins>Ostream</ins>&amp;&amp; os, const T&amp; x);
43146 </pre>
43147 <blockquote>
43148 <p>
43149 1 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
43150 </p>
43151 <p>
43152 2 <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
43153 </p>
43154 <p><ins>
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
43157 <tt>ios_base</tt>.
43158 </ins></p>
43159 </blockquote>
43160 </blockquote>
43161
43162
43163
43164
43165
43166
43167 <hr>
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>
43174 <p>
43175 p6 Iterator requirements 24.2 [iterator.requirements]
43176 </p>
43177
43178 <blockquote>
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
43182 container.
43183 </blockquote>
43184
43185 <p>
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
43189 sentence.
43190 </p>
43191
43192 <p>
43193 An alternative wording might be:
43194 </p>
43195
43196 <blockquote>
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
43199 range.
43200 </blockquote>
43201
43202 <p><i>[
43203 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
43204 ]</i></p>
43205
43206
43207
43208
43209 <p><b>Rationale:</b></p>
43210 <p>
43211 Solved by
43212 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43213 </p>
43214
43215
43216 <p><b>Proposed resolution:</b></p>
43217 <p>
43218 Change 24.2 [iterator.requirements], p6:
43219 </p>
43220
43221 <blockquote>
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
43226 container.</del>
43227 </blockquote>
43228
43229
43230
43231
43232
43233 <hr>
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>
43240 <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>.
43244 </p>
43245
43246 <p>
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.  
43250 </p>
43251
43252 <p>
43253 The second reason comes from the Forward Iterator requirements table:
43254 </p>
43255
43256 <blockquote>
43257 <p>
43258 Forward iterators 24.2.5 [forward.iterators]
43259 </p>
43260
43261 <p>
43262 Table 102 -- Forward iterator requirements
43263 </p>
43264
43265 <blockquote>
43266 For expression <tt>*a</tt> the return type is:
43267 "<tt>T&amp;</tt> if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>"
43268 </blockquote>
43269 </blockquote>
43270
43271 <p>
43272 There is a similar constraint on <tt>a-&gt;m</tt>.
43273 </p>
43274
43275 <p>
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.
43279 </p>
43280
43281 <p>
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.
43285 </p>
43286
43287 <p><i>[
43288 2009-10 post-Santa Cruz:
43289 ]</i></p>
43290
43291
43292 <blockquote>
43293 Move to Open. Howard to put his rationale mentioned above into the issue
43294 as a note.
43295 </blockquote>
43296
43297 <p><i>[
43298 2009-10-26 Howard adds:
43299 ]</i></p>
43300
43301
43302 <blockquote>
43303 <p>
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
43306 input iterator.
43307 </p>
43308
43309 <p>
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.
43315 </p>
43316
43317 <p>
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
43322 place.
43323 </p>
43324
43325 <blockquote><b>
43326 The insert-with-random-access-iterators algorithm is considerably more efficient
43327 than the insert-with-input-iterators algorithm
43328 </b></blockquote>
43329
43330 <p>
43331 Now consider:
43332 </p>
43333
43334 <blockquote><pre>vector&lt;A&gt; v;
43335 <font color="#C80000">//  ... build up a large vector of A ...</font>
43336 vector&lt;A&gt; temp;
43337 <font color="#C80000">//  ... build up a large temporary vector of A to later be inserted ...</font>
43338 typedef move_iterator&lt;vector&lt;A&gt;::iterator&gt; 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>
43342
43343 <p>
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.
43350 </p>
43351
43352 <p>
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.
43356 </p>
43357
43358 <p>
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&lt;bool&gt;::iterator</tt> also does not return
43362 a <tt>bool&amp;</tt> on dereference.  Yet I am not aware of a single vendor that
43363 is willing to ship <tt>vector&lt;bool&gt;::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.
43366 </p>
43367
43368 </blockquote>
43369
43370 <p><i>[
43371 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
43372 ]</i></p>
43373
43374
43375
43376
43377 <p><b>Rationale:</b></p>
43378 <p>
43379 Solved by
43380 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43381 </p>
43382
43383
43384 <p><b>Proposed resolution:</b></p>
43385 <p>
43386 Class template move_iterator 24.5.3.1 [move.iterator]
43387 </p>
43388
43389 <blockquote><pre>namespace std {
43390 template &lt;class Iterator&gt;
43391 class move_iterator {
43392 public:
43393  ...
43394  typedef <del>typename iterator_traits&lt;Iterator&gt;::iterator_category</del> <ins>input_iterator_tag</ins> iterator_category;
43395 </pre></blockquote>
43396
43397
43398
43399
43400
43401 <hr>
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>
43408 <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.
43410 </p>
43411
43412 <p>
43413 Merging row from:
43414 </p>
43415
43416 <blockquote><pre>Table 102 -- Forward iterator requirements
43417 Table 103 -- Bidirectional iterator requirements
43418
43419     r++ : convertible to const X&amp;
43420     r-- : convertible to const X&amp;
43421     
43422     *r++ : T&amp; if X is mutable, otherwise const T&amp;
43423     *r-- : convertible to T
43424 </pre></blockquote>
43425
43426 <p><i>[
43427 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
43428 ]</i></p>
43429
43430
43431
43432
43433 <p><b>Rationale:</b></p>
43434 <p>
43435 Solved by
43436 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
43437 </p>
43438
43439
43440 <p><b>Proposed resolution:</b></p>
43441
43442
43443
43444
43445
43446 <hr>
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>
43453 <p>
43454 Concerning mathematically proper operation of the type:
43455 </p>
43456
43457 <blockquote><pre>complex&lt;complex&lt;T&gt; &gt;
43458 </pre></blockquote>
43459
43460 <p>
43461 Generally accepted mathematical semantics of such a construct correspond
43462 to quaternions through Cayly-Dickson construct
43463 </p>
43464
43465 <blockquote><pre>(w+xi) + (y+zi) j
43466 </pre></blockquote>
43467
43468 <p>
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&lt;double&gt; i=(0,1),  x = 12.34 + 5*i;</tt>
43475 </p>
43476
43477 <p>
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.
43482 </p>
43483
43484 <pre>/////////////////////////ALLOW OPERATORS TO COMBINE REAL SCALARS AND COMPLEX VALUES /////////////////////////
43485 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator+(const complex&lt;T&gt; x,const S a) {
43486     complex&lt;T&gt; result(x.real()+a, x.imag());
43487     return result;
43488 }
43489 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator+(const S a,const complex&lt;T&gt; x) {
43490     complex&lt;T&gt; result(a+x.real(), x.imag());
43491     return result;
43492 }
43493 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator-(const complex&lt;T&gt; x,const S a) {
43494     complex&lt;T&gt; result(x.real()-a, x.imag());
43495     return result;
43496 }
43497 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator-(const S a,const complex&lt;T&gt; x) {
43498     complex&lt;T&gt; result(a-x.real(), x.imag());
43499     return result;
43500 }
43501 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator*(const complex&lt;T&gt; x,const S a) {
43502     complex&lt;T&gt; result(x.real()*a, x.imag()*a);
43503     return result;
43504 }
43505 template&lt;typename T,typename S&gt; complex&lt;T&gt; operator*(const S a,const complex&lt;T&gt; x) {
43506     complex&lt;T&gt; result(a*x.real(), a*x.imag());
43507     return result;
43508 }
43509
43510 /////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS/////////////////////////
43511 template&lt;typename T&gt; double normSq(const complex&lt;complex&lt;T&gt; &gt;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();
43516 }
43517 template&lt;typename T&gt; double norm(const complex&lt;complex&lt;T&gt; &gt;q) {
43518     return sqrt(normSq(q));
43519 }
43520 /////// Cayley-Dickson Construction
43521 template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; conj(const complex&lt;complex&lt;T&gt; &gt; x) {
43522     complex&lt;complex&lt;T&gt; &gt; result(conj(x.real()),-x.imag());
43523     return result;
43524 }
43525 template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator*(const complex&lt;complex&lt;T&gt; &gt; ab,const complex&lt;complex&lt;T&gt; &gt; cd) {
43526     complex&lt;T&gt; re(ab.real()*cd.real()-conj(cd.imag())*ab.imag());
43527     complex&lt;T&gt; im(cd.imag()*ab.real()+ab.imag()*conj(cd.real()));
43528     complex&lt;complex&lt;double&gt; &gt; q(re,im);
43529     return q;
43530 }
43531 //// Quaternion division
43532 template&lt;typename S,typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const complex&lt;complex&lt;T&gt; &gt; q,const S a) {
43533     return q * (1/a);
43534 }
43535 template&lt;typename S,typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const S a,const complex&lt;complex&lt;T&gt; &gt; q) {
43536     return a*conj(q)/normSq(q);
43537 }
43538 template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const complex&lt;complex&lt;T&gt; &gt; n, const complex&lt;complex&lt;T&gt; &gt; d) {
43539     return n * (conj(d)/normSq(d));
43540 }
43541 </pre>
43542
43543 <p><i>[
43544 2009-10 Santa Cruz:
43545 ]</i></p>
43546
43547
43548 <blockquote>
43549 NAD Future.  There is no consensus or time to move this into C++0X.
43550 </blockquote>
43551
43552
43553
43554 <p><b>Proposed resolution:</b></p>
43555
43556
43557
43558
43559
43560 <hr>
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>
43568
43569
43570
43571 <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.
43582 </p>
43583
43584 <p><i>[
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>,
43586 if not a dup.
43587 ]</i></p>
43588
43589
43590 <p><i>[
43591 2009-11-14 Moved to Tentatively Dup after 5 positive votes on c++std-lib.
43592 ]</i></p>
43593
43594
43595
43596
43597 <p><b>Proposed resolution:</b></p>
43598
43599
43600
43601
43602
43603 <hr>
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>
43610 <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>)?
43616 </p>
43617
43618 <p><i>[
43619 2010-02-12 Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
43620 Rationale added below.
43621 ]</i></p>
43622
43623
43624
43625
43626 <p><b>Rationale:</b></p>
43627 <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.
43631 </p>
43632
43633
43634 <p><b>Proposed resolution:</b></p>
43635
43636
43637
43638
43639
43640 <hr>
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>
43647 <p>
43648 For <tt>condition_variable_any</tt>, are recursive mutexes allowed? (I think "no")
43649 </p>
43650
43651 <p><i>[
43652 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
43653 Rationale added below.
43654 ]</i></p>
43655
43656
43657
43658 <p><b>Proposed resolution:</b></p>
43659
43660
43661 <p><b>Rationale:</b></p>
43662 <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.
43669 </p>
43670
43671
43672
43673
43674
43675 <hr>
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>
43682 <p>
43683 I think the text about <tt>std::result_of</tt> could be a little more precise.
43684 Quoting from
43685 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>...
43686 </p>
43687
43688 <blockquote>
43689 <p>
43690 X [func.ret] Function object return types
43691 </p>
43692
43693 <pre>template&lt;class&gt; class result_of;
43694
43695 template&lt;class Fn, class... ArgTypes&gt;
43696 class result_of&lt;Fn(ArgTypes...)&gt; {
43697 public:
43698   typedef <i>see below</i> type;
43699 };
43700 </pre>
43701
43702 <p>
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
43708 rvalues otherwise.
43709 </p>
43710 </blockquote>
43711
43712 <p>
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:
43716 </p>
43717
43718 <blockquote><pre>template&lt;typename Fn, typename... Args&gt;
43719 typename std::result_of&lt;Fn(Args...)&gt;::type
43720 apply(Fn &amp;&amp; fn, Args &amp;&amp; ...args)
43721 {
43722   // Fn may be an lvalue reference, too
43723   return std::forward&lt;Fn&gt;(fn)(std::forward&lt;Args&gt;(args)...);
43724 }
43725 </pre></blockquote>
43726
43727 <p>
43728 Either <tt>std::result_of&lt;...&gt;</tt> can be instantiated and simply may not have
43729 a typedef "<tt>type</tt>" (--&gt;SFINAE) or instantiating the class template for
43730 some type combinations will be a "hard" compile-time error.
43731 </p>
43732
43733 <p><i>[
43734 2010-02-14 Daniel adds:
43735 ]</i></p>
43736
43737
43738 <blockquote>
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.
43741 </blockquote>
43742
43743 <p><i>[
43744 2010 Pittsburgh:  Moved to NAD Editorial, rationale added below.
43745 ]</i></p>
43746
43747
43748
43749
43750 <p><b>Rationale:</b></p>
43751 <p>
43752 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>.
43753 </p>
43754
43755
43756 <p><b>Proposed resolution:</b></p>
43757
43758 <p><i>[
43759 These changes will require compiler support
43760 ]</i></p>
43761
43762
43763 <p>
43764 Change X [func.ret]:
43765 </p>
43766
43767 <blockquote><pre>template&lt;class&gt; class result_of; // <i>undefined</i>
43768
43769 template&lt;class Fn, class... ArgTypes&gt;
43770 class result_of&lt;Fn(ArgTypes...)&gt; {
43771 public:
43772   <del>typedef</del> <i>see below</i> <del>type;</del>
43773 };
43774 </pre>
43775
43776 <p><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
43782 rvalues otherwise.
43783 </del></p>
43784
43785 <p>
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&lt;Fn(T1,T2,...,TN)&gt;</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>
43791 </ins></p>
43792
43793 <blockquote><pre><ins>
43794 value&lt;Fn&gt;() ( value&lt;T1&gt;(), value&lt;T2&gt;(), ... value&lt;TN&gt;()  )
43795 </ins></pre></blockquote>
43796
43797 <p><ins>
43798 would be well-formed. Otherwise, there shall be no member typedef
43799 <tt>type</tt> defined.
43800 </ins></p>
43801
43802 </blockquote>
43803  
43804 <p><i>[
43805 The <tt>value&lt;&gt;</tt> helper function is a utility Daniel Krügler
43806 proposed in
43807 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>.
43808 ]</i></p>
43809
43810
43811
43812
43813
43814
43815 <hr>
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>
43821 <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]:
43824 </p>
43825
43826 <blockquote><pre>extern const error_category* const future_category;
43827 </pre></blockquote>
43828
43829 <p>
43830 which should be similarly transformed into function form.
43831 </p>
43832
43833 <p><i>[
43834 2009-10-27 Howard:
43835 ]</i></p>
43836
43837
43838 <blockquote>
43839 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
43840 </blockquote>
43841
43842 <p><i>[
43843 2009-11-11 Daniel adds:
43844 ]</i></p>
43845
43846
43847 <blockquote>
43848 <p>
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
43852 </p>
43853
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>
43857
43858 <p>
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
43865 </p>
43866
43867 <blockquote><pre>extern const error_category* const future_category;
43868 </pre></blockquote>
43869
43870 <p>
43871 combined with
43872 </p>
43873
43874 <blockquote><pre>constexpr error_code make_error_code(future_errc e);
43875 </pre>
43876 <blockquote>
43877 3 <i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e), *future_category)</tt>.
43878 </blockquote>
43879
43880 <pre>constexpr error_code make_error_condition(future_errc e);
43881 </pre>
43882 <blockquote>
43883 4 <i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e), *future_category)</tt>.
43884 </blockquote>
43885 </blockquote>
43886
43887 <p>
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>).
43892 </p>
43893
43894 <p>
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].
43902 </p>
43903
43904 <p>
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
43908 as possible.
43909 </p>
43910 <p>
43911 What-ever the route is, the following is my proposed resolution for this issue
43912 interaction part of the story:
43913 </p>
43914
43915 <blockquote>
43916 <p>
43917 In 30.6.1 [futures.overview]/1, Header <tt>&lt;future&gt;</tt> synopsis <em>and</em>
43918 in 30.6.2 [futures.errors]/3+4
43919 change as indicated:
43920 </p>
43921
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>
43925 </blockquote>
43926
43927 <p>
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.
43930 </p>
43931
43932 <p><i>[
43933 Howard: I've updated the proposed wording as Daniel suggests and set to Review.
43934 ]</i></p>
43935
43936 </blockquote>
43937
43938 <p><i>[
43939 2009-11-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
43940 ]</i></p>
43941
43942
43943 <p><i>[
43944 2010 Pittsburgh:
43945 ]</i></p>
43946
43947
43948 <blockquote>
43949 Moved to NAD Editorial.  Rationale added below.
43950 </blockquote>
43951
43952
43953
43954 <p><b>Rationale:</b></p>
43955 <p>
43956 Solved by N3058.
43957 </p>
43958
43959
43960 <p><b>Proposed resolution:</b></p>
43961 <ol>
43962 <li>
43963 <p>
43964 Change in 30.6.1 [futures.overview], header <tt>&lt;future&gt;</tt> synopsis:
43965 </p>
43966
43967 <blockquote><pre><del>extern</del> const error_category<ins>&amp;</ins><del>* const</del> future_category<ins>()</ins>;
43968 </pre></blockquote>
43969 </li>
43970
43971 <li>
43972 <p>
43973 In 30.6.1 [futures.overview]/1, Header <tt>&lt;future&gt;</tt> synopsis 
43974 change as indicated:
43975 </p>
43976
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>
43980 </li>
43981
43982 <li>
43983 <p>
43984 Change in 30.6.2 [futures.errors]:
43985 </p>
43986
43987 <blockquote><pre><del>extern</del> const error_category<ins>&amp;</ins><del>* const</del> future_category<ins>()</ins>;
43988 </pre>
43989
43990 <blockquote>
43991 <p>
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>
43994 </p>
43995 <p>
43996 <ins>1- <i>Returns:</i> A reference to an object of a type
43997 derived from class <tt>error_category</tt>.</ins>
43998 </p>
43999 </blockquote>
44000
44001 <pre><del>constexpr</del> error_code make_error_code(future_errc e);
44002 </pre>
44003
44004 <blockquote>
44005 3 <i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
44006 <del>*</del>future_category<ins>()</ins>)</tt>.
44007 </blockquote>
44008
44009 <pre><del>constexpr</del> error_<del>code</del><ins>condition</ins> make_error_condition(future_errc e);
44010 </pre>
44011
44012 <blockquote>
44013 4 <i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e),
44014 <del>*</del>future_category<ins>()</ins>)</tt>.
44015 </blockquote>
44016 </blockquote>
44017 </li>
44018 </ol>
44019
44020
44021
44022
44023
44024 <hr>
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>
44031 <p>
44032 According to p1 20.7.2 [meta.type.synop]:
44033 </p>
44034
44035 <blockquote>
44036 The behavior of a program that adds specializations for any of the class
44037 templates defined in this subclause is undefined unless otherwise
44038 specified.
44039 </blockquote>
44040
44041 <p>
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.
44045 </p>
44046
44047 <p><i>[
44048 2009-10 Santa Cruz:
44049 ]</i></p>
44050
44051
44052 <blockquote>
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.
44057 </blockquote>
44058
44059 <p><i>[
44060 2010 Pittsburgh:  Moved to NAD, rationale added below.
44061 ]</i></p>
44062
44063
44064
44065
44066 <p><b>Rationale:</b></p>
44067 <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>
44070 is superior.
44071 </p>
44072
44073
44074 <p><b>Proposed resolution:</b></p>
44075 <p>
44076 Add the following comment:
44077 </p>
44078
44079 <blockquote>
44080 user specialization permitted to derive from <tt>std::true_type</tt> when the
44081 operation is known not to throw.
44082 </blockquote>
44083
44084 <p>
44085 to the following traits in 20.7.4.3 [meta.unary.prop] Table 43 Type
44086 property predicates.
44087 </p>
44088
44089 <p><i>[
44090 This may require a new Comments column
44091 ]</i></p>
44092
44093
44094 <blockquote><pre>has_nothrow_default_constructor
44095 has_nothrow_copy_constructor
44096 has_nothrow_assign
44097 </pre></blockquote>
44098
44099
44100
44101
44102
44103 <hr>
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>
44109 <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:
44112 </p>
44113
44114 <blockquote><pre> 
44115 template &lt;class ErrorCodeEnum&gt;
44116   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type&amp;
44117     operator=(ErrorCodeEnum e);
44118 </pre></blockquote>
44119
44120 <p>
44121 They should say:
44122 </p>
44123
44124 <blockquote><pre> 
44125 template &lt;class ErrorCodeEnum&gt;
44126   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value, error_code&gt;::type&amp;
44127     operator=(ErrorCodeEnum e);
44128 </pre></blockquote>
44129
44130 <p>
44131 Or (I prefer this form):
44132 </p>
44133  
44134 <blockquote><pre> 
44135 template &lt;class ErrorCodeEnum&gt;
44136   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value, error_code&amp;&gt;::type
44137     operator=(ErrorCodeEnum e);
44138 </pre></blockquote>
44139
44140 <p>
44141 This is because <tt>enable_if</tt> is declared as (20.7.7.6 [meta.trans.other]):
44142 </p>
44143  
44144 <blockquote><pre> 
44145 template &lt;bool B, class T = void&gt; struct enable_if;
44146 </pre></blockquote>
44147
44148 <p>
44149 So, the current wording makes <tt>operator=</tt> return
44150 <tt>void&amp;</tt>, which is not good.
44151 </p>
44152
44153 <p> 
44154 19.5.2.3 [syserr.errcode.modifiers]/4 says
44155 </p>
44156
44157 <blockquote>
44158 <i>Returns:</i> <tt>*this</tt>.
44159 </blockquote>
44160 <p>
44161 which is correct.
44162 </p>
44163
44164 <p>
44165 Additionally,
44166 </p>
44167
44168 <p>
44169 19.5.3.1 [syserr.errcondition.overview]/1 says:
44170 </p>
44171  
44172 <blockquote><pre> 
44173 template&lt;typename ErrorConditionEnum&gt;
44174   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;, error_code&gt;::type &amp;
44175     operator=( ErrorConditionEnum e );
44176 </pre></blockquote>
44177
44178 <p>
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:
44182 </p>
44183  
44184 <blockquote><pre> 
44185 template &lt;class ErrorConditionEnum&gt;
44186   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type&amp;
44187     operator=(ErrorConditionEnum e);
44188 </pre></blockquote>
44189
44190 <p>
44191 Which returns <tt>void&amp;</tt>.  They should both say:
44192 </p>
44193  
44194 <blockquote><pre> 
44195 template &lt;class ErrorConditionEnum&gt;
44196   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value, error_condition&gt;::type&amp;
44197     operator=(ErrorConditionEnum e);
44198 </pre></blockquote>
44199
44200 <p>
44201 Or (again, I prefer this form):
44202 </p>
44203
44204 <blockquote><pre> 
44205 template &lt;class ErrorConditionEnum&gt;
44206   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value, error_condition&amp;&gt;::type
44207     operator=(ErrorConditionEnum e);
44208 </pre></blockquote>
44209
44210 <p>
44211 Additionally, 19.5.3.3 [syserr.errcondition.modifiers] lacks a
44212 "<i>Returns:</i> <tt>*this</tt>." paragraph, which is presumably
44213 necessary.
44214 </p>
44215
44216 <p><i>[
44217 2009-10-18 Beman adds:
44218 ]</i></p>
44219
44220
44221 <blockquote>
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.
44224 </blockquote>
44225
44226 <p><i>[
44227 2009-10 Santa Cruz:
44228 ]</i></p>
44229
44230
44231 <blockquote>
44232 NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.
44233 </blockquote>
44234
44235
44236
44237 <p><b>Proposed resolution:</b></p>
44238
44239 <p>
44240 Change 19.5.2.1 [syserr.errcode.overview] and 19.5.2.3 [syserr.errcode.modifiers]:
44241 </p>
44242
44243 <blockquote><pre>template &lt;class ErrorCodeEnum&gt;
44244   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code&amp;</ins>&gt;::type<del>&amp;</del>
44245     operator=(ErrorCodeEnum e);
44246 </pre></blockquote>
44247
44248 <p>
44249 Change 19.5.3.1 [syserr.errcondition.overview]:
44250 </p>
44251
44252 <blockquote><pre>template&lt;<del>typename</del> <ins>class</ins> ErrorConditionEnum&gt;
44253   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>, error_co<ins>ndition</ins><del>de</del><ins>&amp;</ins>&gt;::type<del> &amp;</del>
44254     operator=( ErrorConditionEnum e );
44255 </pre></blockquote>
44256
44257 <p>
44258 Change 19.5.3.3 [syserr.errcondition.modifiers]:
44259 </p>
44260
44261 <blockquote><pre>template &lt;class ErrorConditionEnum&gt;
44262   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value<ins>, error_condition&amp;</ins>&gt;::type<del>&amp;</del>
44263     operator=(ErrorConditionEnum e);
44264 </pre>
44265 <blockquote>
44266 <p>
44267 <i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
44268 </p>
44269 <p><ins>
44270 <i>Returns:</i> <tt>*this</tt>.
44271 </ins></p>
44272 <p>
44273 <i>Throws:</i> Nothing.
44274 </p>
44275 </blockquote>
44276 </blockquote>
44277
44278
44279
44280
44281
44282
44283 <hr>
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>
44291
44292
44293
44294 <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.
44299 </p>
44300
44301 <p>
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:
44306 </p>
44307
44308 <blockquote><pre>template&lt;class R, class T, typename ... ArgTypes&gt;
44309   unspecified mem_fn(R (T::*pm)(ArgTypes...));
44310 </pre></blockquote>
44311
44312 <p>
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
44315 syntax.
44316 </p>
44317
44318 <p><i>[
44319 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a> as a similar proposed resolution.
44320 ]</i></p>
44321
44322
44323
44324 <p><b>Proposed resolution:</b></p>
44325 Add to 20.8 [function.objects] and 20.8.13 [func.memfn]:
44326
44327
44328 <blockquote><pre>template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm)
44329
44330 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
44331 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
44332 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
44333 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>
44334
44335 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&amp;);</ins>
44336 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&amp;);</ins>
44337 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&amp;);</ins>
44338 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&amp;);</ins>
44339
44340 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&amp;&amp;);</ins>
44341 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&amp;&amp;);</ins>
44342 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&amp;&amp;);</ins>
44343 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&amp;&amp;);</ins>
44344 </pre></blockquote>
44345
44346 <p>
44347 Strike 20.8.13 [func.memfn], p5:
44348 </p>
44349
44350 <blockquote>
44351 <del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set
44352 of overloaded function templates.</del>
44353 </blockquote>
44354
44355
44356
44357
44358 <hr>
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>
44366 <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.
44369 </p>
44370
44371 <p><i>[
44372 2009-10 Santa Cruz:
44373 ]</i></p>
44374
44375
44376 <blockquote>
44377 Editor accepts as NAD Editorial.
44378 </blockquote>
44379
44380
44381
44382 <p><b>Proposed resolution:</b></p>
44383 <ol>
44384 <li>
44385 <p>
44386 Change 20.3.5 [pairs]/1 as indicated:
44387 </p>
44388
44389 <blockquote><pre>template &lt;class T1, class T2&gt;
44390 struct pair {
44391   ...
44392   void swap(pair&amp;<del>&amp;</del> p);
44393 };
44394 </pre></blockquote>
44395 </li>
44396
44397 <li>
44398 <p>
44399 Change 20.3.5 [pairs] before p. 17 as indicated:
44400 </p>
44401
44402 <blockquote><pre>void swap(pair&amp;<del>&amp;</del> p);
44403 </pre></blockquote>
44404
44405 </li>
44406
44407 <li>
44408
44409 <p>
44410 Change 20.3.5 [pairs] before p. 21 as indicated:
44411 </p>
44412
44413 <blockquote><pre>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp; x, pair&lt;T1, T2&gt;&amp; y);
44414 <del>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp;&amp; x, pair&lt;T1, T2&gt;&amp; y);</del>
44415 <del>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp; x, pair&lt;T1, T2&gt;&amp;&amp; y);</del>
44416 </pre></blockquote>
44417
44418 </li>
44419
44420 <li>
44421 <p>
44422 Change 20.4.1 [tuple.general]/2, header <tt>&lt;tuple&gt;</tt> synopsis, as indicated:
44423 </p>
44424
44425 <blockquote><pre>// 20.5.2.9, specialized algorithms:
44426 template &lt;class... Types&gt;
44427 void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
44428 <del>template &lt;class... Types&gt;
44429 void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
44430 template &lt;class... Types&gt;
44431 void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);</del>
44432 </pre></blockquote>
44433
44434 </li>
44435
44436 <li>
44437 <p>
44438 Change 20.4.2 [tuple.tuple] as indicated:
44439 </p>
44440
44441 <blockquote><pre>// 20.5.2.3, tuple swap
44442 void swap(tuple&amp;<del>&amp;</del>)
44443 </pre></blockquote>
44444
44445 </li>
44446
44447 <li>
44448 <p>
44449 Change 20.4.2.3 [tuple.swap] before 1 as indicated:
44450 </p>
44451
44452 <blockquote><pre>void swap(tuple&amp;<del>&amp;</del> rhs);
44453 </pre></blockquote>
44454
44455 </li>
44456
44457 <li>
44458 <p>
44459 Change 20.8 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, as indicated:
44460 </p>
44461
44462 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
44463 void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
44464 <del>template&lt;class R, class... ArgTypes&gt;
44465 void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
44466 template&lt;class R, class... ArgTypes&gt;
44467 void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&amp;&amp;);</del>
44468 </pre></blockquote>
44469
44470 </li>
44471
44472 <li>
44473 <p>
44474 Change 20.8.14.2 [func.wrap.func], as indicated:
44475 </p>
44476
44477 <blockquote><pre>// 20.7.15.2.2, function modifiers:
44478 void swap(function&amp;<del>&amp;</del>);
44479 template&lt;class F, class A&gt; void assign(F, const A&amp;);
44480
44481 [..]
44482
44483 // 20.7.15.2.7, specialized algorithms:
44484 template &lt;class R, class... ArgTypes&gt;
44485 void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
44486 <del>template &lt;class R, class... ArgTypes&gt;
44487 void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
44488 template &lt;class R, class... ArgTypes&gt;
44489 void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</del>
44490 </pre></blockquote>
44491
44492 </li>
44493
44494 <li>
44495 <p>
44496 Change 20.8.14.2.7 [func.wrap.func.alg] before 1 as indicated:
44497 </p>
44498
44499 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
44500 void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
44501 <del>template&lt;class R, class... ArgTypes&gt;
44502 void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
44503 template&lt;class R, class... ArgTypes&gt;
44504 void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</del>
44505 </pre></blockquote>
44506
44507 </li>
44508
44509 <li>
44510 <p>
44511 Change 20.9.10.2 [util.smartptr.shared]/1 as indicated:
44512 </p>
44513
44514 <blockquote><pre>// 20.8.12.2.4, modifiers:
44515 void swap(shared_ptr&amp;<del>&amp;</del> r);
44516
44517 [..]
44518
44519 // 20.8.12.2.9, shared_ptr specialized algorithms:
44520 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
44521 <del>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
44522 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</del>
44523 </pre></blockquote>
44524
44525 </li>
44526
44527 <li>
44528 <p>
44529 Change 21.3 [string.classes]/1, header <tt>&lt;string&gt;</tt> synopsis, as indicated:
44530 </p>
44531
44532 <blockquote><pre>// 21.4.8.8: swap
44533 template&lt;class charT, class traits, class Allocator&gt;
44534 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
44535 <del>template&lt;class charT, class traits, class Allocator&gt;
44536 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
44537 template&lt;class charT, class traits, class Allocator&gt;
44538 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);</del>
44539 </pre></blockquote>
44540
44541 </li>
44542
44543 <li>
44544 <p>
44545 Change 23.3 [sequences]/1, header <tt>&lt;deque&gt;</tt> synopsis, as indicated:
44546 </p>
44547
44548 <blockquote><pre>template &lt;class T, class Allocator&gt;
44549 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44550 <del>template &lt;class T, class Allocator&gt;
44551 void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44552 template &lt;class T, class Allocator&gt;
44553 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
44554 </pre></blockquote>
44555
44556 </li>
44557
44558 <li>
44559 <p>
44560 Change 23.3 [sequences]/1, header <tt>&lt;list&gt;</tt> synopsis, as indicated:
44561 </p>
44562
44563 <blockquote><pre>template &lt;class T, class Allocator&gt;
44564 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44565 <del>template &lt;class T, class Allocator&gt;
44566 void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44567 template &lt;class T, class Allocator&gt;
44568 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
44569 </pre></blockquote>
44570
44571 </li>
44572
44573 <li>
44574 <p>
44575 Change 23.3 [sequences]/1, header <tt>&lt;queue&gt;</tt> synopsis, as indicated:
44576 </p>
44577
44578 <blockquote><pre>template &lt;class T, class Allocator&gt;
44579 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
44580 <del>template &lt;class T, class Container&gt;
44581 void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
44582 template &lt;class T, class Container&gt;
44583 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
44584
44585 template &lt;class T, class Container = vector&lt;T&gt;, class Compare = less&lt;typename Container::value_type&gt; &gt;
44586 class priority_queue;
44587 template &lt;class T, class Container, class Compare&gt;
44588 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44589 <del>template &lt;class T, class Container, class Compare&gt;
44590 void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44591 template &lt;class T, class Container, class Compare&gt;
44592 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
44593 </pre></blockquote>
44594
44595 </li>
44596
44597 <li>
44598 <p>
44599 Change 23.3 [sequences]/1, header <tt>&lt;stack&gt;</tt> synopsis, as indicated:
44600 </p>
44601
44602 <blockquote><pre>template &lt;class T, class Container&gt;
44603 void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp; y);
44604 <del>template &lt;class T, class Container&gt;
44605 void swap(stack&lt;T, Container&gt;&amp;&amp; x, stack&lt;T, Container&gt;&amp; y);
44606 template &lt;class T, class Container&gt;
44607 void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp;&amp; y);</del>
44608 </pre></blockquote>
44609
44610 </li>
44611
44612 <li>
44613 <p>
44614 Change 23.3 [sequences]/1, header <tt>&lt;vector&gt;</tt> synopsis, as indicated:
44615 </p>
44616
44617 <blockquote><pre>template &lt;class T, class Allocator&gt;
44618 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44619 <del>template &lt;class T, class Allocator&gt;
44620 void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44621 template &lt;class T, class Allocator&gt;
44622 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
44623 </pre></blockquote>
44624
44625 </li>
44626
44627 <li>
44628 <p>
44629 Change 23.3.2 [deque]/2 as indicated:
44630 </p>
44631
44632 <blockquote><pre>iterator erase(const_iterator position);
44633 iterator erase(const_iterator first, const_iterator last);
44634 void swap(deque&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
44635 void clear();
44636
44637 [..]
44638
44639 // specialized algorithms:
44640 template &lt;class T, class Allocator&gt;
44641 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44642 <del>template &lt;class T, class Allocator&gt;
44643 void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44644 template &lt;class T, class Allocator&gt;
44645 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
44646 </pre></blockquote>
44647
44648 </li>
44649
44650 <li>
44651 <p>
44652 Change 23.3.2.4 [deque.special] as indicated:
44653 </p>
44654
44655 <blockquote><pre>template &lt;class T, class Allocator&gt;
44656 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44657 <del>template &lt;class T, class Allocator&gt;
44658 void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
44659 template &lt;class T, class Allocator&gt;
44660 void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
44661 </pre></blockquote>
44662
44663 </li>
44664
44665 <li>
44666 <p>
44667 Change 23.3.3 [forwardlist]/2 as indicated:
44668 </p>
44669
44670 <blockquote><pre>iterator erase_after(const_iterator position);
44671 iterator erase_after(const_iterator position, iterator last);
44672 void swap(forward_list&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
44673
44674 [..]
44675
44676 // 23.3.3.6 specialized algorithms:
44677 template &lt;class T, class Allocator&gt;
44678 void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
44679 <del>template &lt;class T, class Allocator&gt;
44680 void swap(forward_list&lt;T,Allocator&gt;&amp;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
44681 template &lt;class T, class Allocator&gt;
44682 void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp;&amp; y);</del>
44683 </pre></blockquote>
44684
44685 </li>
44686
44687 <li>
44688 <p>
44689 Change 23.3.3.6 [forwardlist.spec] as indicated:
44690 </p>
44691
44692 <blockquote><pre>template &lt;class T, class Allocator&gt;
44693 void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
44694 <del>template &lt;class T, class Allocator&gt;
44695 void swap(forward_list&lt;T,Allocator&gt;&amp;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
44696 template &lt;class T, class Allocator&gt;
44697 void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp;&amp; y);</del>
44698 </pre></blockquote>
44699
44700 </li>
44701
44702 <li>
44703 <p>
44704 Change 23.3.4 [list]/2 as indicated:
44705 </p>
44706
44707 <blockquote><pre>iterator erase(const_iterator position);
44708 iterator erase(const_iterator position, const_iterator last);
44709 void swap(list&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
44710 void clear();
44711
44712 [..]
44713
44714 // specialized algorithms:
44715 template &lt;class T, class Allocator&gt;
44716 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44717 <del>template &lt;class T, class Allocator&gt;
44718 void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44719 template &lt;class T, class Allocator&gt;
44720 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
44721 </pre></blockquote>
44722
44723 </li>
44724
44725 <li>
44726 <p>
44727 Change 23.3.4.5 [list.special] as indicated:
44728 </p>
44729
44730 <blockquote><pre>template &lt;class T, class Allocator&gt;
44731 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44732 <del>template &lt;class T, class Allocator&gt;
44733 void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
44734 template &lt;class T, class Allocator&gt;
44735 void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
44736 </pre></blockquote>
44737
44738 </li>
44739
44740 <li>
44741 <p>
44742 Change 23.5.1.1 [queue.defn] as indicated:
44743 </p>
44744
44745 <blockquote><pre>void swap(queue&amp;<del>&amp;</del> q) { c.swap(q.c); }
44746
44747 [..]
44748
44749 template &lt;class T, class Container&gt;
44750 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
44751 <del>template &lt;class T, class Container&gt;
44752 void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
44753 template &lt;class T, class Container&gt;
44754 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
44755 </pre></blockquote>
44756
44757 </li>
44758
44759 <li>
44760 <p>
44761 Change 23.5.1.5 [queue.special] as indicated:
44762 </p>
44763
44764 <blockquote><pre>template &lt;class T, class Container&gt;
44765 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
44766 <del>template &lt;class T, class Container&gt;
44767 void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
44768 template &lt;class T, class Container&gt;
44769 void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
44770 </pre></blockquote>
44771
44772 </li>
44773
44774 <li>
44775 <p>
44776 Change 23.5.2 [priority.queue]/1 as indicated:
44777 </p>
44778
44779 <blockquote><pre>void swap(priority_queue&amp;<del>&amp;</del>);
44780
44781 // no equality is provided
44782 template &lt;class T, class Container, class Compare&gt;
44783 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44784 <del>template &lt;class T, class Container, class Compare&gt;
44785 void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44786 template &lt;class T, class Container, class Compare&gt;
44787 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
44788 </pre></blockquote>
44789
44790 </li>
44791
44792 <li>
44793 <p>
44794 Change 23.5.2.4 [priqueue.special] as indicated:
44795 </p>
44796
44797 <blockquote><pre>template &lt;class T, class Container, Compare&gt;
44798 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44799 <del>template &lt;class T, class Container, Compare&gt;
44800 void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
44801 template &lt;class T, class Container, Compare&gt;
44802 void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
44803 </pre></blockquote>
44804
44805 </li>
44806
44807 <li>
44808 <p>
44809 Change 23.5.3.1 [stack.defn] as indicated:
44810 </p>
44811
44812 <blockquote><pre>void swap(stack&amp;<del>&amp;</del> s) { c.swap(s.c); }
44813
44814 [..]
44815
44816 template &lt;class T, class Allocator&gt;
44817 void swap(stack&lt;T,Allocator&gt;&amp; x, stack&lt;T,Allocator&gt;&amp; y);
44818 <del>template &lt;class T, class Allocator&gt;
44819 void swap(stack&lt;T,Allocator&gt;&amp;&amp; x, stack&lt;T,Allocator&gt;&amp; y);
44820 template &lt;class T, class Allocator&gt;
44821 void swap(stack&lt;T,Allocator&gt;&amp; x, stack&lt;T,Allocator&gt;&amp;&amp; y);</del>
44822 </pre></blockquote>
44823
44824
44825 </li>
44826
44827 <li>
44828 <p>
44829 Change 23.5.3.5 [stack.special] as indicated:
44830 </p>
44831
44832 <blockquote><pre>template &lt;class T, class Container&gt;
44833 void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp; y);
44834 <del>template &lt;class T, class Container&gt;
44835 void swap(stack&lt;T, Container&gt;&amp;&amp; x, stack&lt;T, Container&gt;&amp; y);
44836 template &lt;class T, class Container&gt;
44837 void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp;&amp; y);</del>
44838 </pre></blockquote>
44839
44840 </li>
44841
44842 <li>
44843 <p>
44844 Change 23.4.1 [vector]/2 as indicated:
44845 </p>
44846
44847 <blockquote><pre>void swap(vector&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
44848 void clear();
44849
44850 [..]
44851
44852 // specialized algorithms:
44853 template &lt;class T, class Allocator&gt;
44854 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44855 <del>template &lt;class T, class Allocator&gt;
44856 void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44857 template &lt;class T, class Allocator&gt;
44858 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
44859 </pre></blockquote>
44860
44861 </li>
44862
44863 <li>
44864 <p>
44865 Change 23.4.1.2 [vector.capacity] before p. 8 as indicated:
44866 </p>
44867
44868 <blockquote><pre>void swap(vector&lt;T,Allocator&gt;&amp;<del>&amp;</del> x);
44869 </pre></blockquote>
44870
44871 </li>
44872
44873 <li>
44874 <p>
44875 Change 23.4.1.5 [vector.special] as indicated:
44876 </p>
44877
44878 <blockquote><pre>template &lt;class T, class Allocator&gt;
44879 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44880 <del>template &lt;class T, class Allocator&gt;
44881 void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
44882 template &lt;class T, class Allocator&gt;
44883 void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
44884 </pre></blockquote>
44885
44886 </li>
44887
44888 <li>
44889 <p>
44890 Change 23.4.2 [vector.bool]/1 as indicated:
44891 </p>
44892
44893 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44894 void swap(vector&lt;bool,Allocator&gt;&amp;<del>&amp;</del>);
44895 static void swap(reference x, reference y);
44896 </pre></blockquote>
44897
44898 </li>
44899
44900 <li>
44901 <p>
44902 Change 23.6 [associative]/1, header <tt>&lt;map&gt;</tt> synopsis as indicated:
44903 </p>
44904
44905 <blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
44906 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44907 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44908 void swap(map&lt;Key,T,Compare,Allocator&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44909 template &lt;class Key, class T, class Compare, class Allocator&gt;
44910 void swap(map&lt;Key,T,Compare,Allocator&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44911
44912 [..]
44913
44914 template &lt;class Key, class T, class Compare, class Allocator&gt;
44915 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
44916 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44917 void swap(multimap&lt;Key,T,Compare,Allocator&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
44918 template &lt;class Key, class T, class Compare, class Allocator&gt;
44919 void swap(multimap&lt;Key,T,Compare,Allocator&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44920 </pre></blockquote>
44921
44922 </li>
44923
44924 <li>
44925 <p>
44926 Change 23.6 [associative]/1, header <tt>&lt;set&gt;</tt> synopsis as indicated:
44927 </p>
44928
44929 <blockquote><pre>template &lt;class Key, class Compare, class Allocator&gt;
44930 void swap(set&lt;Key,Compare,Allocator&gt;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
44931 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44932 void swap(set&lt;Key,T,Compare,Allocator&amp;&amp; x, set&lt;Key,T,Compare,Allocator&gt;&amp; y);
44933 template &lt;class Key, class T, class Compare, class Allocator&gt;
44934 void swap(set&lt;Key,T,Compare,Allocator&amp; x, set&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44935
44936 [..]
44937
44938 template &lt;class Key, class Compare, class Allocator&gt;
44939 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
44940 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44941 void swap(multiset&lt;Key,T,Compare,Allocator&amp;&amp; x, multiset&lt;Key,T,Compare,Allocator&gt;&amp; y);
44942 template &lt;class Key, class T, class Compare, class Allocator&gt;
44943 void swap(multiset&lt;Key,T,Compare,Allocator&amp; x, multiset&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44944 </pre></blockquote>
44945
44946 </li>
44947
44948 <li>
44949 <p>
44950 Change 23.6.1 [map]/2 as indicated:
44951 </p>
44952
44953 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44954 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp;<del>&amp;</del>);
44955 void clear();
44956
44957 [..]
44958
44959 // specialized algorithms:
44960 template &lt;class Key, class T, class Compare, class Allocator&gt;
44961 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44962 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44963 void swap(map&lt;Key,T,Compare,Allocator&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44964 template &lt;class Key, class T, class Compare, class Allocator&gt;
44965 void swap(map&lt;Key,T,Compare,Allocator&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44966 </pre></blockquote>
44967
44968 </li>
44969
44970 <li>
44971 <p>
44972 Change 23.6.1.5 [map.special] as indicated:
44973 </p>
44974
44975 <blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
44976 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44977 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
44978 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
44979 template &lt;class Key, class T, class Compare, class Allocator&gt;
44980 void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
44981 </pre></blockquote>
44982
44983 </li>
44984
44985 <li>
44986 <p>
44987 Change 23.6.2 [multimap]/2 as indicated:
44988 </p>
44989
44990 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
44991 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp;<del>&amp;</del>);
44992 void clear();
44993
44994 [..]
44995
44996 // specialized algorithms:
44997 template &lt;class Key, class T, class Compare, class Allocator&gt;
44998 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
44999 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
45000 void swap(multimap&lt;Key,T,Compare,Allocator&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
45001 template &lt;class Key, class T, class Compare, class Allocator&gt;
45002 void swap(multimap&lt;Key,T,Compare,Allocator&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
45003 </pre></blockquote>
45004
45005 </li>
45006
45007 <li>
45008 <p>
45009 Change 23.6.2.4 [multimap.special] as indicated:
45010 </p>
45011
45012 <blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
45013 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
45014 <del>template &lt;class Key, class T, class Compare, class Allocator&gt;
45015 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
45016 template &lt;class Key, class T, class Compare, class Allocator&gt;
45017 void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
45018 </pre></blockquote>
45019
45020 </li>
45021
45022 <li>
45023 <p>
45024 Change 23.6.3 [set]/2 and 23.6.3.2 [set.special] as indicated: (twice!)
45025 </p>
45026
45027 <blockquote><pre>// specialized algorithms:
45028 template &lt;class Key, class Compare, class Allocator&gt;
45029 void swap(set&lt;Key,Compare,Allocator&gt;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
45030 <del>template &lt;class Key, class Compare, class Allocator&gt;
45031 void swap(set&lt;Key,Compare,Allocator&amp;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
45032 template &lt;class Key, class Compare, class Allocator&gt;
45033 void swap(set&lt;Key,Compare,Allocator&amp; x, set&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
45034 </pre></blockquote>
45035
45036 </li>
45037
45038 <li>
45039 <p>
45040 Change 23.6.4 [multiset]/2 as indicated:
45041 </p>
45042
45043 <blockquote><pre>iterator erase(const_iterator first, const_iterator last);
45044 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp;<del>&amp;</del>);
45045 void clear();
45046
45047 [..]
45048
45049 // specialized algorithms:
45050 template &lt;class Key, class Compare, class Allocator&gt;
45051 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
45052 <del>template &lt;class Key, class Compare, class Allocator&gt;
45053 void swap(multiset&lt;Key,Compare,Allocator&amp;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
45054 template &lt;class Key, class Compare, class Allocator&gt;
45055 void swap(multiset&lt;Key,Compare,Allocator&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
45056 </pre></blockquote>
45057
45058 </li>
45059
45060 <li>
45061 <p>
45062 Change 23.6.4.2 [multiset.special] as indicated:
45063 </p>
45064
45065 <blockquote><pre>template &lt;class Key, class Compare, class Allocator&gt;
45066 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
45067 <del>template &lt;class Key, class Compare, class Allocator&gt;
45068 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
45069 template &lt;class Key, class Compare, class Allocator&gt;
45070 void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
45071 </pre></blockquote>
45072
45073 </li>
45074 </ol>
45075
45076
45077
45078
45079
45080 <hr>
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>
45087 <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].
45090 </p>
45091
45092 <p><i>[
45093 2009-11-04 Howard adds:
45094 ]</i></p>
45095
45096
45097 <blockquote>
45098 Moved to Tentatively NAD Editorial.  The editor has adopted the fix.
45099 </blockquote>
45100
45101
45102 <p><b>Proposed resolution:</b></p>
45103 <p>
45104 Add in 20.9 [memory], Header <tt>&lt;memory&gt;</tt> synopsis
45105 missing declarations as shown below:
45106 </p>
45107
45108 <blockquote><pre>// 20.8.11 Class unique_ptr:
45109 template &lt;class X&gt; class default_delete;
45110 <ins>template&lt;class T&gt; struct default_delete&lt;T[]&gt;;</ins>
45111 template &lt;class X, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
45112 <ins>template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;</ins>
45113
45114 <ins>template&lt;class T, class D&gt; void swap(unique_ptr&lt;T, D&gt;&amp; x, unique_ptr&lt;T, D&gt;&amp; y);</ins>
45115
45116 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45117 bool operator==(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45118 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45119 bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45120 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45121 bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45122 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45123 bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45124 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45125 bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45126 <ins>template&lt;class T1, class D1, class T2, class D2&gt;
45127 bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);</ins>
45128 </pre></blockquote>
45129
45130
45131
45132
45133
45134 <hr>
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>
45140 <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.
45149 </p>
45150
45151 <p>
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:
45155 </p>
45156
45157 <blockquote><pre>namespace mkl {
45158  class mt19937 {.... };
45159 }
45160 </pre></blockquote>
45161
45162 <p>
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
45165 example:
45166 </p>
45167
45168 <blockquote><pre>mkl::mt19937 eng;
45169 std::normal_distribution&lt;double&gt; dist;
45170
45171 double n = dist(eng);
45172 </pre></blockquote>
45173
45174 <p>
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
45179 achieved.
45180 </p>
45181
45182 <p>
45183 Contrast this with TR1:
45184 </p>
45185
45186 <blockquote><pre>mkl::mt19937 eng;
45187 std::tr1::normal_distribution&lt;double&gt; dist;
45188 std::tr1::variate_generator&lt;mkl::mt19937,std::tr1::normal_distribution&lt;double&gt; &gt; rng(eng,dist);
45189 double n = rng();
45190 </pre></blockquote>
45191
45192 <p>
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>:
45196 </p>
45197
45198 <blockquote><pre>namespace std { namespace tr1 {
45199
45200 template&lt;&gt;
45201 class variate_generator&lt;mkl::mt19937,std::tr1::normal_distribution&lt;double&gt; &gt; { .... };
45202
45203 } }
45204 </pre></blockquote>
45205
45206 <p>
45207 A similar customization point is missing in the C++0x design and
45208 prevents the optimized vectorized version to be used.
45209 </p>
45210
45211 <p>
45212 Suggested resolution:
45213 </p>
45214
45215 <p>
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:
45220 </p>
45221
45222 <blockquote><pre>template &lt;RandomNumberDistribution, class RandomNumberEngine&gt;
45223 typename RandomNumberDistribution ::result_type
45224 generate_variate(RandomNumberDistribution const&amp; dist, RandomNumberEngine&amp; eng);
45225 </pre></blockquote>
45226
45227 <p>
45228 This function can be overloaded for optimized enginges like
45229 <tt>mkl::mt19937</tt>.
45230 </p>
45231
45232 <p><i>[
45233 2009-10 Santa Cruz:
45234 ]</i></p>
45235
45236
45237 <blockquote>
45238 NAD Future.  No time to add this feature for C++0X.
45239 </blockquote>
45240
45241
45242
45243 <p><b>Proposed resolution:</b></p>
45244
45245
45246
45247
45248
45249 <hr>
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>
45257 <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
45261 you sort it out.
45262 </p>
45263
45264 <p>
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.
45274 </p>
45275
45276 <p>
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
45282 get</tt>"?
45283 </p>
45284
45285 <p><i>[
45286 2009 Santa Cruz:
45287 ]</i></p>
45288
45289
45290 <blockquote>
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.
45295 </blockquote>
45296
45297
45298
45299 <p><b>Proposed resolution:</b></p>
45300
45301
45302
45303
45304
45305 <hr>
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>
45312 <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
45319 25.
45320 </p>
45321
45322 <p>
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>
45325 but this
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.
45330 </p>
45331
45332 <p>
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
45336 behaviours.
45337 </p>
45338
45339 <p>
45340 Motivating examples:
45341 </p>
45342
45343 <p>
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) &lt; 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).
45352 </p>
45353
45354 <p>
45355 A second motivating example might be the <tt>copy</tt> algorithm.  Specifically,
45356 let us image a call like:
45357 </p>
45358
45359 <blockquote><pre>copy(istream_iterator&lt;int&gt;(is),istream_iterator(),ostream_iterator&lt;int&gt;(os));
45360 </pre></blockquote>
45361
45362 <p>
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&lt;int&gt;{}</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>.
45371 </p>
45372
45373 <p>
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
45375 two.
45376 </p>
45377
45378 <p>
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.
45385 </p>
45386
45387 <p>
45388 I suspect we want some wording similar to:
45389 </p>
45390
45391 <blockquote>
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.
45395 </blockquote>
45396
45397 <p>
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.
45403 </p>
45404
45405 <p>
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.
45409 </p>
45410
45411 <p>
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
45414 these constraints.
45415 </p>
45416
45417 <p><i>[
45418 2009-11-03 Howard adds:
45419 ]</i></p>
45420
45421
45422 <blockquote>
45423 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
45424 </blockquote>
45425
45426
45427 <p><b>Rationale:</b></p>
45428 <p>
45429 Does not have sufficient support at this time. May wish to reconsider for a
45430 future standard.
45431 </p>
45432
45433
45434 <p><b>Proposed resolution:</b></p>
45435
45436
45437
45438
45439
45440 <hr>
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>
45447 <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>:
45451 </p>
45452
45453 <blockquote>
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.
45456 </blockquote>
45457
45458 <p><i>[
45459 2009-10 post-Santa Cruz:
45460 ]</i></p>
45461
45462
45463 <blockquote>
45464 <p>
45465 An array of a trivial type is a trivial type.
45466 </p>
45467 <p>
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.
45471 </p>
45472 </blockquote>
45473
45474
45475
45476 <p><b>Rationale:</b></p>
45477 <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.
45480 </p>
45481
45482
45483 <p><b>Proposed resolution:</b></p>
45484 <p>
45485 Change all the traits in question following this pattern:
45486 </p>
45487
45488 <blockquote>
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.
45491 </blockquote>
45492
45493 <p>
45494 i.e., add a comma and delete a "class."
45495 </p>
45496
45497
45498
45499
45500
45501 <hr>
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>
45508 <p>
45509 See
45510 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2980.pdf">N2980</a>.
45511 </p>
45512
45513
45514 <p><b>Proposed resolution:</b></p>
45515
45516
45517
45518
45519
45520 <hr>
45521 <h3><a name="1243"></a>1243. Missing <tt>operator+= (initializer_list&lt;T&gt;)</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>
45528
45529 <p>
45530 During the additions of <tt>initializer_list</tt> overloads
45531 <tt>basic_string</tt> added
45532 </p>
45533
45534 <blockquote><pre>basic_string&amp; operator+=(initializer_list&lt;charT&gt;);
45535 </pre></blockquote>
45536
45537 <p>
45538 but
45539 </p>
45540
45541 <blockquote><pre>valarray&lt;T&gt;&amp; operator+= (initializer_list&lt;T&gt;);
45542 </pre></blockquote>
45543
45544 <p>
45545 was not defined.
45546 </p>
45547
45548 <p><i>[
45549 Daniel adds on opening:
45550 ]</i></p>
45551
45552
45553 <blockquote>
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).
45561 </blockquote>
45562
45563 <p><i>[
45564 2009-10 Santa Cruz:
45565 ]</i></p>
45566
45567
45568 <blockquote>
45569 Mark as NAD.  Request has been withdrawn by NB.
45570 </blockquote>
45571
45572
45573
45574 <p><b>Proposed resolution:</b></p>
45575 <p>
45576 Add to 26.6.2.6 [valarray.cassign]:
45577 </p>
45578
45579 <blockquote><pre>valarray&lt;T&gt;&amp; operator+= (initializer_list&lt;T&gt;);
45580 </pre></blockquote>
45581
45582
45583
45584
45585
45586 <hr>
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>
45593 <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.
45598 </p>
45599
45600 <p>
45601 Suggested resolution:
45602 </p>
45603
45604 <p>
45605 Throw an exception.
45606 </p>
45607
45608 <p><i>[
45609 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
45610 ]</i></p>
45611
45612
45613
45614
45615 <p><b>Rationale:</b></p>
45616 <p>
45617 Solved by
45618 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
45619 </p>
45620
45621
45622 <p><b>Proposed resolution:</b></p>
45623
45624
45625
45626
45627
45628 <hr>
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>
45635 <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:
45639 </p>
45640
45641 <blockquote><pre>void resize(size_type sz);
45642 </pre>
45643 <blockquote>
45644 <i>Effects:</i> If <tt>sz &lt; size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
45645 <tt>size() &lt; sz</tt>, appends <tt>sz - size()</tt> default constructed elements to the
45646 sequence.
45647 </blockquote>
45648 </blockquote>
45649
45650 <p>
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?
45653 </p>
45654
45655 <p><i>[
45656 2009-11-10 Howard adds:
45657 ]</i></p>
45658
45659
45660 <blockquote>
45661 Moved to Tentatively NAD after 5 positive votes on c++std-lib.  Rationale added
45662 below.
45663 </blockquote>
45664
45665
45666
45667 <p><b>Proposed resolution:</b></p>
45668 <p>
45669 In 23.4.1.2 [vector.capacity]/10, change
45670 </p>
45671
45672 <blockquote><pre>void resize(size_type sz);
45673 </pre>
45674 <blockquote>
45675 <i>Effects:</i> If <tt>sz &lt; size()</tt>, equivalent to <tt>erase(begin() + sz, end());</tt>. If
45676 <tt>size() &lt; sz</tt>, <del>appends <tt>sz - size()</tt> default constructed elements to the
45677 sequence</del>
45678 <ins>equivalent to <tt>sz - size()</tt> consecutive evaluations of <tt>push_back(T())</tt></ins>.
45679 </blockquote>
45680 </blockquote>
45681
45682
45683
45684 <p><b>Rationale:</b></p>
45685 <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.
45692 </p>
45693
45694
45695
45696
45697
45698 <hr>
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>
45705 <p>
45706 See
45707 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
45708 </p>
45709
45710 <p><i>[
45711 2010-01-22 Alisdair Opens.
45712 ]</i></p>
45713
45714
45715 <p><i>[
45716 2010-01-24 Alisdair provides wording.
45717 ]</i></p>
45718
45719
45720 <p><i>[
45721 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
45722 ]</i></p>
45723
45724
45725
45726
45727 <p><b>Rationale:</b></p>
45728 <p>
45729 Solved by
45730 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3068.pdf">N3068</a>.
45731 </p>
45732
45733
45734 <p><b>Proposed resolution:</b></p>
45735 <p>
45736 Apply paper
45737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
45738 </p>
45739
45740
45741
45742
45743
45744 <hr>
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>
45751 <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.
45754 </p>
45755 <p>
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
45759 to move.
45760 </p>
45761
45762 <p>
45763 I.e., the <tt>ostringstream(ostringstream &amp;&amp;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.
45768 </p>
45769
45770 <p>
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.
45775 </p>
45776
45777 <p><i>[
45778 2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
45779 Rationale added below.
45780 ]</i></p>
45781
45782
45783
45784 <p><b>Rationale:</b></p>
45785 <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.
45793 </p>
45794
45795
45796 <p><b>Proposed resolution:</b></p>
45797 <p>
45798 Strike from 27.8.1.1 [stringbuf.cons]:
45799 </p>
45800
45801 <blockquote><pre>basic_stringbuf(basic_stringbuf&amp;&amp; rhs);
45802 </pre>
45803 <blockquote>
45804 <p>
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.
45812 </p>
45813
45814 <p>
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.
45818 </p>
45819 <ul>
45820 <li>
45821 <tt>str() == rhs_p.str()</tt>
45822 </li>
45823 <li>
45824 <tt>gptr() - eback() == rhs_p.gptr() - rhs_p.eback()</tt>
45825 </li>
45826 <li>
45827 <tt>egptr() - eback() == rhs_p.egptr() - rhs_p.eback()</tt>
45828 </li>
45829 <li>
45830 <tt>pptr() - pbase() == rhs_p.pptr() - rhs_p.pbase()</tt>
45831 </li>
45832 <li>
45833 <tt>epptr() - pbase() == rhs_p.epptr() - rhs_p.pbase()</tt>
45834 </li>
45835 <li><del>
45836 if <tt>(eback()) eback() != rhs_a.eback()</tt>
45837 </del></li>
45838 <li><del>
45839 if <tt>(gptr()) gptr() != rhs_a.gptr()</tt>
45840 </del></li>
45841 <li><del>
45842 if <tt>(egptr()) egptr() != rhs_a.egptr()</tt>
45843 </del></li>
45844 <li><del>
45845 if <tt>(pbase()) pbase() != rhs_a.pbase()</tt>
45846 </del></li>
45847 <li><del>
45848 if <tt>(pptr()) pptr() != rhs_a.pptr()</tt>
45849 </del></li>
45850 <li><del>
45851 if <tt>(epptr()) epptr() != rhs_a.epptr()</tt>
45852 </del></li>
45853 </ul>
45854 </blockquote>
45855 </blockquote>
45856
45857
45858
45859
45860
45861
45862 <hr>
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>
45869 <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.
45876 </p>
45877
45878 <p><i>[
45879 2009-11-10 Howard adds:
45880 ]</i></p>
45881
45882
45883 <blockquote>
45884 I've moved this issue to Tentatively NAD after 5 positive votes on c++std-lib,
45885 and added a rationale below.
45886 </blockquote>
45887
45888
45889 <p><b>Proposed resolution:</b></p>
45890 <p>
45891 </p>
45892
45893
45894 <p><b>Rationale:</b></p>
45895 <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
45900 survey.
45901 </p>
45902
45903
45904
45905
45906
45907 <hr>
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>
45913
45914 <p><b>Addresses: UK 314</b></p>
45915
45916 <p>
45917 In Message c++std-lib-25529, Alisdair writes:
45918 </p>
45919
45920 <blockquote>
45921 <p>
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
45924 were missed.
45925 </p>
45926
45927 <p>
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 &lt;g&gt;
45932 </p>
45933
45934 <p>
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!)
45938 </p>
45939 </blockquote>
45940
45941 <p><i>[
45942 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
45943 ]</i></p>
45944
45945
45946
45947 <p><b>Proposed resolution:</b></p>
45948
45949
45950 <p><b>Rationale:</b></p>
45951 <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.
45955 </p>
45956
45957
45958
45959
45960
45961 <hr>
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>
45968 <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>:
45973 </p>
45974
45975 <blockquote><pre>void foo() {
45976   jump_buf buf;
45977   non_trivial_dtor n1; // 1
45978   if (!setjmp(buf)) {
45979     non_trivial_dtor n2; // 2
45980     try {
45981       longjmp(buf, 1);
45982     } catch (...) {
45983     }
45984   }
45985 }
45986 </pre></blockquote>
45987
45988 <p>
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
45997 cause Bad Things.
45998 </p>
45999
46000 <p>
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).
46007 </p>
46008
46009 <p>
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:
46012 </p>
46013
46014 <blockquote>
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.
46021 </blockquote>
46022
46023 <p><i>[
46024 2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. 
46025 Rationale added below.
46026 ]</i></p>
46027
46028
46029
46030 <p><b>Proposed resolution:</b></p>
46031 <p>
46032 Change 18.10 [support.runtime]/4:
46033 </p>
46034
46035 <blockquote>
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>
46045 call.</ins>
46046 </blockquote>
46047
46048
46049 <p><b>Rationale:</b></p>
46050 <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>.
46053 </p>
46054 <p>
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.
46058 </p>
46059
46060
46061
46062
46063
46064 <hr>
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>
46071 <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):
46078 </p>
46079
46080 <blockquote>
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.
46083 </blockquote>
46084
46085 <p>
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.
46088 </p>
46089
46090 <p><i>[
46091 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
46092 ]</i></p>
46093
46094
46095
46096
46097 <p><b>Rationale:</b></p>
46098 <p>
46099 Solved by
46100 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46101 </p>
46102
46103
46104 <p><b>Proposed resolution:</b></p>
46105 <p>
46106 Replace 30.6.7 [futures.shared_future]p22 with the following:
46107 </p>
46108
46109 <blockquote>
46110 <p>
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>.
46118 </ins></p>
46119
46120 <p><ins>
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.
46126 </ins></p>
46127
46128 <p><ins>
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.
46136 </ins></p>
46137
46138 <p><ins>
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.
46142 </ins></p>
46143 </blockquote>
46144
46145
46146
46147
46148
46149 <hr>
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>
46157 <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.
46161 </p>
46162
46163 <p><i>[
46164 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
46165 ]</i></p>
46166
46167
46168
46169
46170 <p><b>Rationale:</b></p>
46171 <p>
46172 Solved by
46173 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46174 </p>
46175
46176
46177 <p><b>Proposed resolution:</b></p>
46178 <p>
46179 Add a new sentence to 30.6.4 [futures.state] p2:
46180 </p>
46181
46182 <blockquote>
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>
46188 </blockquote>
46189
46190 <p>
46191 Add an extra bullet to 30.6.4 [futures.state] p3:
46192 </p>
46193
46194 <blockquote>
46195 <p>
46196 The result of an associated state can be set by calling:
46197 </p>
46198 <ul>
46199 <li>
46200 <tt>promise::set_value</tt>,
46201 </li>
46202 <li>
46203 <tt>promise::set_exception</tt>, <del>or</del>
46204 </li>
46205 <li>
46206 packaged_task::operator()<del>.</del><ins>, or</ins>
46207 </li>
46208 <li>
46209 <ins>a call to <tt>async</tt> (30.6.9 [futures.async]).</ins>
46210 </li>
46211 </ul>
46212 </blockquote>
46213
46214
46215
46216
46217
46218 <hr>
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>
46226 <p>
46227 The definitions of <tt>promise::set_value</tt> need tidying up, the
46228 synopsis says:
46229 </p>
46230
46231 <blockquote><pre>// setting the result
46232 void set_value(const R&amp; r);
46233 void set_value(<i>see below</i>);
46234 </pre></blockquote>
46235
46236 <p>
46237 Why is the first one there?  It implies it is always present for all
46238 specialisations of promise, which is not true.
46239 </p>
46240
46241 <p>
46242 The definition says:
46243 </p>
46244
46245 <blockquote><pre>void set_value(const R&amp; r);
46246 void promise::set_value(R&amp;&amp; r);
46247 void promise&lt;R&amp;&gt;::set_value(R&amp; r);
46248 void promise&lt;void&gt;::set_value();
46249 </pre></blockquote>
46250
46251 <p>
46252 The lack of qualification on the first one again implies it's present
46253 for all specialisations, again not true.
46254 </p>
46255
46256 <p><i>[
46257 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
46258 ]</i></p>
46259
46260
46261
46262
46263 <p><b>Rationale:</b></p>
46264 <p>
46265 Solved by
46266 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46267 </p>
46268
46269
46270 <p><b>Proposed resolution:</b></p>
46271 <p>
46272 Change the synopsis in 30.6.5 [futures.promise]:
46273 </p>
46274
46275 <blockquote><pre>// setting the result
46276 <del>void set_value(const R&amp; r);</del>
46277 void set_value(<i>see below</i>);
46278 </pre></blockquote>
46279
46280 <p>
46281 And the definition be changed by qualifying the first signature:
46282 </p>
46283
46284 <blockquote><pre>void <ins>promise::</ins>set_value(const R&amp; r);
46285 void promise::set_value(R&amp;&amp; r);
46286 void promise&lt;R&amp;&gt;::set_value(R&amp; r);
46287 void promise&lt;void&gt;::set_value();
46288 </pre></blockquote>
46289
46290
46291
46292
46293
46294 <hr>
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>
46301 <p>
46302 30.6.6 [futures.unique_future]/3 says:
46303 </p>
46304
46305 <blockquote>
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.
46309 </blockquote>
46310
46311 <p>
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!
46314 </p>
46315
46316 <p><i>[
46317 2009-12-08 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
46318 ]</i></p>
46319
46320
46321 <p><i>[
46322 2010 Pittsburgh:
46323 ]</i></p>
46324
46325
46326 <blockquote>
46327 Moved to NAD Editorial.  Rationale added below.
46328 </blockquote>
46329
46330
46331
46332 <p><b>Rationale:</b></p>
46333 <p>
46334 Solved by N3058.
46335 </p>
46336
46337
46338 <p><b>Proposed resolution:</b></p>
46339 <p>
46340 Change 30.6.6 [futures.unique_future]/3:
46341 </p>
46342
46343 <blockquote>
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.
46348 </blockquote>
46349
46350
46351
46352
46353
46354
46355 <hr>
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>
46362 <p>
46363 In 30.6.8 [futures.atomic_future] this constructor:
46364 </p>
46365
46366 <blockquote><pre>atomic_future(future&lt;R&gt;&amp;&amp;);
46367 </pre></blockquote>
46368
46369 <p>
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>
46372 defines:
46373 </p>
46374
46375 <blockquote><pre>atomic_future(const future&lt;R&gt;&amp;&amp; rhs);
46376 </pre></blockquote>
46377
46378 <p>
46379 and
46380 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">n3000</a>
46381 defines
46382 </p>
46383
46384 <blockquote><pre>atomic_future(atomic_future&lt;R&gt;&amp;&amp; rhs);
46385 </pre></blockquote>
46386
46387 <p>
46388 both of which are wrong. The constructor definition should be changed
46389 to match the synopsis.
46390 </p>
46391
46392 <p><i>[
46393 2009-12-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
46394 ]</i></p>
46395
46396
46397 <p><i>[
46398 2010 Pittsburgh:
46399 ]</i></p>
46400
46401
46402 <blockquote>
46403 Moved to NAD Editorial.  Rationale added below.
46404 </blockquote>
46405
46406
46407
46408 <p><b>Rationale:</b></p>
46409 <p>
46410 Solved by N3058.
46411 </p>
46412
46413
46414 <p><b>Proposed resolution:</b></p>
46415 <p>
46416 Adjust the signature above 30.6.8 [futures.atomic_future]/6 like so:
46417 </p>
46418
46419 <blockquote><pre>atomic_future(<del>atomic_</del>future<ins>&lt;R&gt;</ins>&amp;&amp; rhs);
46420 </pre></blockquote>
46421
46422
46423
46424
46425
46426 <hr>
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>
46433 <p>
46434 30.6.6 [futures.unique_future]/1 should be updated to mention
46435 <tt>async</tt>.
46436 </p>
46437
46438 <p>
46439 30.6.7 [futures.shared_future]/1 should also be updated for
46440 <tt>async</tt>. That paragraph also says
46441 </p>
46442
46443 <blockquote>
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.
46446 </blockquote>
46447
46448 <p>
46449 How can the value be set by a <tt>shared_future</tt>?
46450 </p>
46451
46452 <p>
46453 30.6.8 [futures.atomic_future]/1 says
46454 </p>
46455
46456 <blockquote>
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.
46460 </blockquote>
46461
46462 <p>
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
46466 <tt>async</tt>.
46467 </p>
46468
46469 <p><i>[
46470 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
46471 ]</i></p>
46472
46473
46474
46475
46476 <p><b>Rationale:</b></p>
46477 <p>
46478 Solved by
46479 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
46480 </p>
46481
46482
46483 <p><b>Proposed resolution:</b></p>
46484
46485
46486
46487
46488
46489 <hr>
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>
46496 <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.
46502 </p>
46503
46504 <p>
46505 Two <tt>ratio</tt> classes <tt>ratio&lt;N1,D1&gt;</tt> and
46506 <tt>ratio&lt;N2,D2&gt;</tt> have the same normalized form if
46507 </p>
46508
46509 <blockquote><pre>ratio&lt;N1, D1&gt;::num == ratio&lt;N2, D2&gt;::num &amp;&amp;
46510 ratio&lt;N1, D1&gt;::den == ratio&lt;N2, D2&gt;::den
46511 </pre></blockquote>
46512
46513 <p>
46514 This simple example
46515 </p>
46516
46517 <blockquote><pre>ratio&lt;1,3&gt; r1;
46518 ratio&lt;3,9&gt; r2;
46519 r1 = r2; // (1)
46520 </pre></blockquote>
46521
46522 <p>
46523 fails to compile in (1). Other example
46524 </p>
46525
46526 <blockquote><pre>ratio&lt;1,3&gt; r1;
46527 ratio_subtract&lt;ratio&lt;2,3&gt;, ratio&lt;1,3&gt;&gt;::type r2;
46528 r1 = r2;  
46529 </pre></blockquote>
46530
46531 <p>
46532 The nested type of <tt>ratio_subtract&lt;ratio&lt;2,3&gt;,
46533 ratio&lt;1,3&gt;&gt;</tt> could be <tt>ratio&lt;3,9&gt;</tt> so the compilation
46534 could fail. It could also be <tt>ratio&lt;1,3&gt;</tt> and the compilation
46535 succeeds.
46536 </p>
46537
46538 <p>
46539 In 20.6.2 [ratio.arithmetic] 3 and similar clauses
46540 </p>
46541
46542 <blockquote>
46543 3 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
46544 T2&gt;</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>.
46546 </blockquote>
46547
46548 <p>
46549 the meaning of synonym let think that the result shall be a normalized
46550 <tt>ratio</tt> equivalent to <tt>ratio&lt;T1, T2&gt;</tt>, but there is not an
46551 explicit definition of what synonym means in this context.
46552 </p>
46553
46554 <p>
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.
46558 </p>
46559
46560 <p><i>[
46561 2010 Pittsburgh:
46562 ]</i></p>
46563
46564
46565 <blockquote>
46566 <p>
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.
46569 </p>
46570
46571 <p>
46572 Proposed wording modified.  Original proposed wording preserved here.  Moved to
46573 Review.
46574 </p>
46575
46576 <blockquote class="note">
46577 <p>
46578 Make <tt>ratio</tt> default constructible, copy-constructible and assignable
46579 from any <tt>ratio</tt> which has the same reduced form.
46580 </p>
46581
46582 <p>
46583 Add to 20.6.1 [ratio.ratio] synopsis
46584 </p>
46585
46586 <blockquote><pre>template &lt;intmax_t N, intmax_t D = 1&gt;
46587 class ratio {
46588 public:
46589   static constexpr intmax_t num;
46590   static constexpr intmax_t den;
46591
46592   <ins>typedef ratio&lt;num, den&gt; type;</ins>
46593
46594   <ins>ratio() = default;
46595   template &lt;intmax_t N2, intmax_t D2&gt;
46596     ratio(const ratio&lt;N2, D2&gt;&amp;);
46597   template &lt;intmax_t N2, intmax_t D2&gt;
46598     ratio&amp; operator=(const ratio&lt;N2, D2&gt;&amp;);</ins>
46599 };
46600 </pre></blockquote>
46601
46602 <p>
46603 Add to 20.6.1 [ratio.ratio]:
46604 </p>
46605
46606 <blockquote>
46607 <p>
46608 Two ratio classes <tt>ratio&lt;N1,D1&gt;</tt> and <tt>ratio&lt;N2,D2&gt;</tt>
46609 have the same reduced form if <tt>ratio&lt;N1,D1&gt;::type</tt> is the same
46610 type as <tt>ratio&lt;N2,D2&gt;::type</tt>
46611 </p>
46612
46613 </blockquote>
46614
46615 <p>
46616 Add a new section: [ratio.cons]
46617 </p>
46618
46619 <blockquote>
46620 <p><b>
46621 Construction and assignment  [ratio.cons]
46622 </b></p>
46623
46624 <pre>template &lt;intmax_t N2, intmax_t D2&gt;
46625   ratio(const ratio&lt;N2, D2&gt;&amp; r);
46626 </pre>
46627
46628 <blockquote>
46629 <p>
46630 <i>Effects:</i> Constructs a <tt>ratio</tt> object.
46631 </p>
46632 <p>
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>.
46635 </p>
46636 </blockquote>
46637
46638 <pre>template &lt;intmax_t N2, intmax_t D2&gt;
46639   ratio&amp; operator=(const ratio&lt;N2, D2&gt;&amp; r);
46640 </pre>
46641
46642 <blockquote>
46643 <p>
46644 <i>Effects:</i> None.
46645 </p>
46646 <p>
46647 <i>Returns:</i> <tt>*this</tt>.
46648 </p>
46649 <p>
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>.
46652 </p>
46653 </blockquote>
46654
46655 </blockquote>
46656
46657 <p>
46658 Change 20.6.2 [ratio.arithmetic] 
46659 </p>
46660
46661 <blockquote>
46662 <p>
46663 Implementations may use other algorithms to compute these values. If overflow
46664 occurs, a diagnostic shall be issued.
46665 </p>
46666
46667 <pre>template &lt;class R1, class R2&gt; struct ratio_add {
46668   typedef <i>see below</i> type;
46669 };
46670 </pre>
46671
46672 <blockquote>
46673 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
46674 T2&gt;<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 *
46676 R2::den</tt>.
46677 </blockquote>
46678
46679 <pre>template &lt;class R1, class R2&gt; struct ratio_subtract {
46680   typedef <i>see below</i> type;
46681 };
46682 </pre>
46683
46684 <blockquote>
46685 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
46686 T2&gt;<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 *
46688 R2::den</tt>.
46689 </blockquote>
46690
46691 <pre>template &lt;class R1, class R2&gt; struct ratio_multiply {
46692   typedef <i>see below</i> type;
46693 };
46694 </pre>
46695
46696 <blockquote>
46697 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
46698 T2&gt;<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>.
46700 </blockquote>
46701
46702 <pre>template &lt;class R1, class R2&gt; struct ratio_divide {
46703   typedef <i>see below</i> type;
46704 };
46705 </pre>
46706
46707 <blockquote>
46708 The nested typedef <tt>type</tt> shall be a synonym for <tt>ratio&lt;T1,
46709 T2&gt;<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>.
46711 </blockquote>
46712
46713 </blockquote>
46714
46715 </blockquote>
46716
46717 </blockquote>
46718
46719 <p><i>[
46720 2010-03-27 Howard adds:
46721 ]</i></p>
46722
46723
46724 <blockquote>
46725 <p>
46726 Daniel brought to my attention the recent addition of the typedef <tt>type</tt>
46727 to the FCD
46728 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>:
46729 </p>
46730
46731 <blockquote><pre>typedef ratio type;
46732 </pre></blockquote>
46733
46734 <p>
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&lt;N, D&gt;</tt>, but the typedef is intended to refer to
46739 <tt>ratio&lt;num, den&gt;</tt> which in general is not the same type.
46740 </p>
46741
46742 <p>
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>.
46745 </p>
46746
46747 </blockquote>
46748
46749 <p><i>[Batavia: NAD Editorial - see rationale below]</i></p>
46750
46751
46752
46753
46754 <p><b>Rationale:</b></p>Already fixed in working draft
46755
46756 <p><b>Proposed resolution:</b></p>
46757 <p>
46758 Add to 20.6.1 [ratio.ratio] synopsis
46759 </p>
46760
46761 <blockquote><pre>template &lt;intmax_t N, intmax_t D = 1&gt;
46762 class ratio {
46763 public:
46764   static constexpr intmax_t num;
46765   static constexpr intmax_t den;
46766
46767   typedef ratio<ins>&lt;num, den&gt;</ins> type;
46768 };
46769 </pre></blockquote>
46770
46771
46772
46773
46774
46775
46776 <hr>
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>
46783 <ol type="I">
46784
46785 <li>
46786 <p>
46787 Motivation and Scope
46788 </p>
46789 <p>
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&lt;&gt;</tt> to split string into
46793 parts, but there are several inconvenient restrictions:
46794 </p>
46795
46796 <ul>
46797 <li>
46798 we cannot explicitly assign the set of delimiters;
46799 </li>
46800 <li>
46801 this approach is suitable only for strings, but not for other types of
46802 containers;
46803 </li>
46804 <li>
46805 we have (possible) performance leak due to string instantiation.
46806 </li>
46807 </ul>
46808 </li>
46809
46810 <li>
46811 <p>
46812 Impact on the Standard
46813 </p>
46814 <p>
46815 This algorithm doesn't interfere with any of current standard algorithms.
46816 </p>
46817 </li>
46818
46819 <li>
46820 <p>
46821 Design Decisions
46822 </p>
46823 <p>
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.
46826 </p>
46827 </li>
46828
46829 <li>
46830 <p>
46831 Example implementation
46832 </p>
46833 <pre>template&lt; class It, class DelimIt, class OutIt &gt;
46834 void split( It begin, It end, DelimIt d_begin, DelimIt d_end, OutIt out )
46835 {
46836    while ( begin != end )
46837    {
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&lt; typename It::value_type &gt;() ) );
46842    }
46843 }
46844
46845 template&lt; class It, class CharType, class OutIt &gt;
46846 void split( It begin, It end, const CharType * delim, OutIt out )
46847 {
46848    split( begin, end, delim, delim + std::strlen( delim ), out );
46849 }
46850 </pre>
46851 </li>
46852
46853 <li>
46854 <p>
46855 Usage
46856 </p>
46857 <pre>std::string ss( "word1 word2 word3" );
46858 std::vector&lt; std::pair&lt; std::string::const_iterator, std::string::const_iterator &gt; &gt; v;
46859 split( ss.begin(), ss.end(), " ", std::back_inserter( v ) );
46860
46861 for ( int i = 0; i &lt; v.size(); ++i )
46862 {
46863    std::cout &lt;&lt; std::string( v[ i ].first, v[ i ].second ) &lt;&lt; std::endl;
46864 }
46865 // word1
46866 // word2
46867 // word3
46868 </pre>
46869 </li>
46870
46871 </ol>
46872
46873 <p><i>[
46874 2010-01-22 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
46875 Rationale added below.
46876 ]</i></p>
46877
46878
46879
46880 <p><b>Rationale:</b></p>
46881 <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
46884 standard.
46885 </p>
46886
46887
46888 <p><b>Proposed resolution:</b></p>
46889 <p>
46890 Add to the synopsis in 25.1 [algorithms.general]:
46891 </p>
46892
46893 <blockquote><pre>template&lt; class ForwardIterator1, class ForwardIterator2, class OutputIterator &gt;
46894   void split( ForwardIterator1 first, ForwardIterator1 last,
46895               ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
46896               OutputIterator result );
46897
46898 template&lt; class ForwardIterator1, class CharType, class OutputIterator &gt;
46899   void split( ForwardIterator1 first, ForwardIterator1 last,
46900               const CharType * delimiters, OutputIterator result );
46901 </pre></blockquote>
46902
46903 <p>
46904 Add a new section [alg.split]:
46905 </p>
46906
46907 <blockquote><pre>template&lt; class ForwardIterator1, class ForwardIterator2, class OutputIterator &gt;
46908   void split( ForwardIterator1 first, ForwardIterator1 last,
46909               ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last,
46910               OutputIterator result );
46911 </pre>
46912
46913 <blockquote>
46914 <p>
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&lt;ForwardIterator1,
46918 ForwardIterator1&gt;</tt>. Each of these pairs specifies a maximal subrange of
46919 <tt>[first, last)</tt> which does not contain a delimiter.
46920 </p>
46921 <p>
46922 2. <i>Returns:</i> nothing.
46923 </p>
46924 <p>
46925 3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
46926 </p>
46927 </blockquote>
46928
46929 <pre>template&lt; class ForwardIterator1, class CharType, class OutputIterator &gt;
46930   void split( ForwardIterator1 first, ForwardIterator1 last,
46931               const CharType * delimiters, OutputIterator result );
46932 </pre>
46933
46934 <blockquote>
46935 <p>
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&lt;ForwardIterator1, ForwardIterator1&gt;</tt>. Each of these
46940 pairs specifies a maximal subrange of <tt>[first, last)</tt> which does not
46941 contain a delimiter.
46942 </p>
46943 <p>
46944 2. <i>Returns:</i> nothing.
46945 </p>
46946 <p>
46947 3. <i>Complexity:</i> Exactly <tt>last - first</tt> assignments.
46948 </p>
46949 </blockquote>
46950
46951 </blockquote>
46952
46953
46954
46955
46956
46957 <hr>
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>
46964 <p>
46965 In section 20.2.5 [allocator.requirements], Table 40 \97 Allocator requirements,
46966 the following expression is required for allocator pointers:
46967 </p>
46968
46969 <blockquote>
46970 <table border="1">
46971 <caption>Table 40 \97 Allocator requirements</caption>
46972 <tbody><tr>
46973 <th>Expression</th>
46974 <th>Return type</th>
46975 <th>Assertion/note<br>pre-/post-condition</th>
46976 <th>Default</th>
46977 </tr>
46978 <tr>
46979 <td><tt>static_cast&lt;X::pointer&gt;(w)</tt></td>
46980 <td><tt>X::pointer</tt></td>
46981 <td><tt>static_cast&lt;X::pointer&gt;(w) == p</tt></td>
46982 <td>&nbsp;</td>
46983 </tr>
46984 </tbody></table>
46985 </blockquote>
46986
46987 <p>
46988 To achieve this expression, a smart pointer writer must introduce an explicit
46989 conversion operator from <tt>smart_ptr&lt;void&gt;</tt> to
46990 <tt>smart_ptr&lt;T&gt;</tt> so that
46991 <tt>static_cast&lt;pointer&gt;(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:
46994 </p>
46995
46996 <blockquote><pre>smart_ptr&lt;void&gt; smart_v = ...;
46997 smart_ptr&lt;T&gt; smart_t(smart_v);
46998 </pre></blockquote>
46999
47000 <p>
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&lt;X::pointer&gt;(w)</tt>
47006 expression with a user customizable (via ADL)
47007 <tt>static_pointer_cast&lt;value_type&gt;(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.
47010 </p>
47011
47012 <p>
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":
47018 </p>
47019
47020 <blockquote>
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
47025 does not apply.
47026 </blockquote>
47027
47028 <p>
47029 So we can do this:
47030 </p>
47031
47032 <blockquote><pre>template&lt;class BasePtr&gt;
47033 void generic_ptr_swap(BasePtr p)
47034 {
47035   //ADL customization point
47036   swap(p, p);
47037   //...
47038 }
47039 </pre></blockquote>
47040
47041 <p>
47042 but not the following:
47043 </p>
47044
47045 <blockquote><pre>template&lt;class BasePtr&gt;
47046 void generic_ptr_algo(BasePtr p)
47047 {
47048   typedef std::pointer_traits&lt;BasePtr&gt;::template
47049      rebind&lt;Derived&gt; DerivedPtr;
47050   DerivedPtr dp = static_pointer_cast&lt;Derived&gt;(p);
47051 }
47052 </pre></blockquote>
47053
47054 <p>
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:
47059 </p>
47060
47061 <blockquote><pre>namespace std{
47062
47063 template&lt;typename U, typename T&gt;
47064 <i>unspecified</i>
47065 static_pointer_cast(T&amp;&amp;) = delete;
47066
47067 }
47068
47069 template&lt;class BasePtr&gt;
47070 void generic_ptr_algo(BasePtr p)
47071 {
47072   typedef std::pointer_traits&lt;BasePtr&gt;::template
47073      rebind&lt;Derived&gt; DerivedPtr;
47074
47075   //ADL applies because static_pointer_cast is made
47076   //  visible according to [temp.arg.explicit]/8
47077   using std::static_pointer_cast;
47078
47079   DerivedPtr dp = static_pointer_cast&lt;Derived&gt;(p);
47080
47081   //...
47082 }
47083 </pre></blockquote>
47084
47085 <p>
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.
47090 </p>
47091
47092 <p><i>[
47093 2010-03-26 Daniel made editorial adjustments to the proposed wording.
47094 ]</i></p>
47095
47096
47097 <p><i>[
47098 Moved to NAD Future at 2010-11 Batavia
47099 ]</i></p>
47100
47101 <blockquote>
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"
47104 </blockquote>
47105
47106
47107
47108 <p><b>Proposed resolution:</b></p>
47109 <p>
47110 Add to section 20.3 [utility] Utility components, Header
47111 <tt>&lt;utility&gt;</tt> synopsis:
47112 </p>
47113
47114 <blockquote><pre>// 20.3.X, generic pointer cast functions
47115
47116 template&lt;typename U, typename T&gt;
47117 <i>unspecified</i>
47118 static_pointer_cast(T&amp;&amp;) = delete;
47119
47120 template&lt;typename U, typename T&gt;
47121 <i>unspecified</i>
47122 dynamic_pointer_cast(T&amp;&amp;) = delete;
47123
47124 template&lt;typename U, typename T&gt;
47125 <i>unspecified</i>
47126 const_pointer_cast(T&amp;&amp;) = delete;
47127
47128 //Overloads for raw pointers
47129 template&lt;typename U, typename T&gt;
47130 auto static_pointer_cast(T* t) -&gt; decltype(static_cast&lt;U*&gt;(t));
47131
47132 template&lt;typename U, typename T&gt;
47133 auto dynamic_pointer_cast(T* t) -&gt; decltype(dynamic_cast&lt;U*&gt;(t));
47134
47135 template&lt;typename U, typename T&gt;
47136 auto const_pointer_cast(T* t) -&gt; decltype(const_cast&lt;U*&gt;(t));
47137 </pre></blockquote>
47138
47139 <p>
47140 Add to section 20.3 [utility] Utility components, a new subclause
47141 20.3.X Pointer cast utilities [pointer.cast]:
47142 </p>
47143
47144 <blockquote>
47145 <p>
47146 20.3.X Pointer cast utilities [pointer.cast]
47147 </p>
47148
47149 <p>
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.
47153 </p>
47154
47155 <pre>//Generic declarations
47156 template&lt;typename U, typename T&gt;
47157 <i>unspecified</i>
47158 static_pointer_cast(T&amp;&amp;) = delete;
47159
47160 template&lt;typename U, typename T&gt;
47161 <i>unspecified</i>
47162 dynamic_pointer_cast(T&amp;&amp;) = delete;
47163
47164 template&lt;typename U, typename T&gt;
47165 <i>unspecified</i>
47166 const_pointer_cast(T&amp;&amp;) = delete;
47167 </pre>
47168
47169 <p>
47170 2 The library also defines overloads of these functions for raw pointers.
47171 </p>
47172
47173 <pre>//Overloads for raw pointers
47174 template&lt;typename U, typename T&gt;
47175 auto static_pointer_cast(T* t) -&gt; decltype(static_cast&lt;U*&gt;(t));
47176 </pre>
47177
47178 <blockquote>
47179 <i>Returns:</i> <tt>static_cast&lt;U*&gt;(t)</tt>
47180 </blockquote>
47181
47182 <pre>template&lt;typename U, typename T&gt;
47183 auto dynamic_pointer_cast(T* t) -&gt; decltype(dynamic_cast&lt;U*&gt;(t));
47184 </pre>
47185
47186 <blockquote>
47187 <i>Returns:</i> <tt>dynamic_cast&lt;U*&gt;(t)</tt>
47188 </blockquote>
47189
47190 <pre>template&lt;typename U, typename T&gt;
47191 auto const_pointer_cast(T* t) -&gt; decltype(const_cast&lt;U*&gt;(t));
47192 </pre>
47193
47194 <blockquote>
47195 <i>Returns:</i> <tt>const_cast&lt;U*&gt;(t)</tt>
47196 </blockquote>
47197
47198 <p>
47199 [<i>Example:</i>
47200 </p>
47201
47202 <blockquote><pre>#include &lt;utility&gt; //static_pointer_cast
47203 #include &lt;memory&gt;  //pointer_traits
47204
47205 class Base{};
47206 class Derived : public Base{};
47207
47208 template&lt;class BasePtr&gt;
47209 void generic_pointer_code(BasePtr b)
47210 {
47211    typedef std::pointer_traits&lt;BasePtr&gt;::template
47212       rebind&lt;Derived&gt; DerivedPtr;
47213
47214    using std::static_pointer_cast;
47215    //ADL applies now that static_pointer_cast is visible
47216    DerivedPtr d = static_pointer_cast&lt;Derived&gt;(b);
47217 }
47218 </pre></blockquote>
47219
47220 <p>
47221 \97 <i>end example</i>]
47222 </p>
47223
47224 </blockquote>
47225
47226 <p>
47227 Replace in section 20.2.5 [allocator.requirements] Table 40 \97 Allocator
47228 requirements, the following table entries for allocator pointers:
47229 </p>
47230
47231 <blockquote>
47232 <table border="1">
47233 <caption>Table 40 \97 Allocator requirements</caption>
47234 <tbody><tr>
47235 <th>Expression</th>
47236 <th>Return type</th>
47237 <th>Assertion/note<br>pre-/post-condition</th>
47238 <th>Default</th>
47239 </tr>
47240
47241 <tr>
47242 <td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::pointer</del><ins>T</ins>&gt;(w)</tt></td>
47243 <td><tt>X::pointer</tt></td>
47244 <td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::pointer</del><ins>T</ins>&gt;(w) == p</tt></td>
47245 <td>&nbsp;</td>
47246 </tr>
47247
47248 <tr>
47249 <td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::const_pointer</del><ins>const T</ins>&gt;(w)</tt></td>
47250 <td><tt>X::const_pointer</tt></td>
47251 <td><tt>static<ins>_pointer</ins>_cast&lt;<del>X::const_pointer</del><ins>const T</ins>&gt;(z) == q</tt></td>
47252 <td>&nbsp;</td>
47253 </tr>
47254
47255 </tbody></table>
47256 </blockquote>
47257
47258
47259
47260
47261
47262
47263 <hr>
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>
47271 <p>
47272 In 30.6.5 [futures.promise]
47273 </p>
47274
47275 <p>
47276 Does <tt>promise&lt;R&gt;::set_value</tt> return normally if the copy/move
47277 constructor of <tt>R</tt> throws?
47278 </p>
47279
47280 <p>
47281 The exception could be caught and set using
47282 <tt>promise&lt;R&gt;::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.
47285 </p>
47286
47287 <p>
47288 N.B. This doesn't apply to <tt>promise&lt;R&amp;&gt;::set_value</tt> or
47289 <tt>promise&lt;void&gt;::set_value</tt> because they don't construct a new
47290 object.
47291 </p>
47292
47293 <p><i>[
47294 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
47295 ]</i></p>
47296
47297
47298
47299
47300 <p><b>Rationale:</b></p>
47301 <p>
47302 Solved by
47303 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
47304 </p>
47305
47306
47307 <p><b>Proposed resolution:</b></p>
47308 <p>
47309 Change 30.6.5 [futures.promise]/18:
47310 </p>
47311
47312 <blockquote>
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>.
47317 </blockquote>
47318
47319
47320
47321
47322
47323 <hr>
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>
47330 <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.
47335 </p>
47336
47337 <p>
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
47343 prohibited.
47344 </p>
47345
47346 <p>
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.)
47353 </p>
47354
47355 <p>
47356 (Note that there are no similar problems for unordered maps, nor any of the set
47357 variants)
47358 </p>
47359
47360 <p><i>[
47361 2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.
47362 Rationale added below.
47363 ]</i></p>
47364
47365
47366 <p><b>Rationale:</b></p>
47367 <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.
47371 </p>
47372
47373
47374
47375
47376 <p><b>Proposed resolution:</b></p>
47377 <p>
47378 p2 23.6.1 [map]:
47379 Above the declaration of class <tt>value_compare</tt> in the map synopsis, add:
47380 </p>
47381
47382 <blockquote><pre>template &lt;class Key, class T, class Compare = less&lt;Key&gt;,
47383           class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
47384 class map {
47385 public:
47386   // types:
47387   ...
47388   <ins>// exposition only.</ins>
47389   class value_compare
47390     : public binary_function&lt;value_type,value_type,bool&gt; {
47391     ...
47392 </pre></blockquote>
47393
47394
47395
47396 <p>
47397 p2 23.6.2 [multimap]:
47398 Above the declaration of class <tt>value_compare</tt> in the map synopsis, add:
47399 </p>
47400
47401 <blockquote><pre>template &lt;class Key, class T, class Compare = less&lt;Key&gt;,
47402           class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
47403 class multimap {
47404 public:
47405   // types:
47406   ...
47407   <ins>// exposition only.</ins>
47408   class value_compare
47409     : public binary_function&lt;value_type,value_type,bool&gt; {
47410     ...
47411 </pre></blockquote>
47412
47413
47414
47415
47416
47417 <hr>
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>
47425 <p>
47426 30.6.5 [futures.promise]/12 defines the effects of
47427 <tt>promise::swap(promise&amp;)</tt> as
47428 </p>
47429
47430 <blockquote><pre>void swap(promise&amp; other);
47431 </pre>
47432 <blockquote>
47433 12 <i>Effects:</i> <tt>swap(*this, other)</tt>
47434 </blockquote>
47435 </blockquote>
47436
47437 <p>
47438 and 30.6.5 [futures.promise]/25 defines <tt>swap(promise&lt;R&amp;&gt;,
47439 promise&lt;R&gt;&amp;)</tt> as
47440 </p>
47441
47442 <blockquote><pre>template &lt;class R&gt;
47443   void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
47444 </pre>
47445 <blockquote>
47446 25 <i>Effects:</i> <tt>x.swap(y)</tt>.
47447 </blockquote>
47448 </blockquote>
47449
47450 <p><i>[
47451 2010-01-13 Daniel added "Throws: Nothing."
47452 ]</i></p>
47453
47454
47455 <p><i>[
47456 2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47457 ]</i></p>
47458
47459
47460 <p><i>[
47461 2010 Pittsburgh:
47462 ]</i></p>
47463
47464
47465 <blockquote>
47466 Moved to NAD Editorial.  Rationale added below.
47467 </blockquote>
47468
47469
47470
47471 <p><b>Rationale:</b></p>
47472 <p>
47473 Solved by N3058.
47474 </p>
47475
47476
47477 <p><b>Proposed resolution:</b></p>
47478 <p>
47479 Change 30.6.5 [futures.promise] paragraph 12
47480 </p>
47481
47482 <blockquote><pre>void swap(promise&amp; other);
47483 </pre>
47484 <blockquote>
47485 <p>
47486 12 <i>Effects:</i> <del><tt>swap(*this, other)</tt></del> <ins>Exchanges the
47487 associated
47488 states of <tt>*this</tt> and <tt>other</tt>.</ins>
47489 </p>
47490 <p>
47491 13 ...
47492 </p>
47493 <p><ins>
47494 <i>Throws:</i> Nothing.
47495 </ins></p>
47496 </blockquote>
47497 </blockquote>
47498
47499
47500
47501
47502
47503
47504 <hr>
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>
47511 <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.
47514 </p>
47515
47516 <blockquote>
47517 <p>
47518 To: C++ libraries mailing list<br>
47519 Message c++std-lib-26465
47520 </p>
47521
47522 <p>
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>
47526 </p>
47527
47528 <p>
47529 Bjarne Stroustrup schrieb/wrote:
47530 </p>
47531
47532 <blockquote>
47533 <p>
47534 To: C++ libraries mailing list<br>
47535 Message c++std-lib-26458
47536 </p>
47537
47538 <p>
47539 in table 94 we define <tt>clear()</tt> as:
47540 </p>
47541
47542 <blockquote><pre>a.clear() void erase(begin(), end())
47543 post: size() == 0
47544 </pre></blockquote>
47545
47546 <p>
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?
47550 </p>
47551 </blockquote>
47552 </blockquote>
47553
47554 <p><i>[
47555 2010-01-23 Alisdiar provides wording.
47556 ]</i></p>
47557
47558
47559 <p><i>[
47560 2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47561 ]</i></p>
47562
47563
47564 <p><i>[
47565 2010-01-30 Daniel opens:
47566 ]</i></p>
47567
47568
47569 <blockquote>
47570 <p>
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).
47585 </p>
47586 <p>
47587 Before I will provide explicit wording, I would like to
47588 discuss these points.
47589 </p>
47590
47591 <p>
47592 [1] <tt>std::list</tt> does fortunately specify that clear does not invalidate
47593 the past-the-end iterator.
47594 </p>
47595 </blockquote>
47596
47597 <p><i>[
47598 2010-02-08 Moved to Tentatively NAD Editorial after 5 positive votes on c++std-lib.
47599 Rationale added below.
47600 ]</i></p>
47601
47602
47603
47604
47605 <p><b>Rationale:</b></p>
47606 <p>
47607 Solved as proposed by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>.
47608 </p>
47609
47610
47611 <p><b>Proposed resolution:</b></p>
47612
47613 <p>
47614 Change 23.2.1 [container.requirements.general]/10:
47615 </p>
47616
47617 <blockquote>
47618 <p>
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
47621 requirements:
47622 </p>
47623
47624 <ul>
47625 <li>
47626 ..
47627 </li>
47628
47629 <li>
47630 no <tt>erase()</tt>, <ins><tt>clear()</tt>,</ins> <tt>pop_back()</tt> or
47631 <tt>pop_front()</tt> function throws an exception.
47632 </li>
47633
47634 <li>
47635 ...
47636 </li>
47637 </ul>
47638
47639 </blockquote>
47640
47641 <p>
47642 Replace the following words from Table 94 \97 Sequence container
47643 requirements (in addition to container) in 23.2.3 [sequence.reqmts]:
47644 </p>
47645
47646 <blockquote>
47647 <table border="1">
47648 <caption>Table 94 \97 Sequence container requirements (in addition to
47649 container)</caption>
47650 <tbody><tr>
47651 <th>Expression</th>
47652 <th>Return type</th>
47653 <th>Assertion/note<br>pre-/post-condition</th>
47654 </tr>
47655
47656 <tr>
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>
47664 </tr>
47665 </tbody></table>
47666 </blockquote>
47667
47668 <p>
47669 Add a new paragraph after 23.3.3.4 [forwardlist.modifiers]/23:
47670 </p>
47671
47672 <blockquote><pre>void clear();
47673 </pre>
47674
47675 <blockquote>
47676 <p>
47677 23 <i>Effects:</i> Erases all elements in the range <tt>[begin(),end())</tt>.
47678 </p>
47679 <p><ins>
47680 <i>Remarks:</i> Does not invalidate past-the-end iterators.
47681 </ins></p>
47682 </blockquote>
47683 </blockquote>
47684
47685
47686
47687
47688
47689
47690 <hr>
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>
47698 <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>
47701 </p>
47702
47703 <blockquote><pre>vector&lt;T&gt; v;
47704 v.emplace(v.begin(),x,y,z)
47705 </pre></blockquote>
47706
47707 <p>
47708 now has a different semantics than
47709 </p>
47710
47711 <blockquote><pre>set&lt;T&gt; s;
47712 s.emplace(s.begin(),x,y,z);
47713 </pre></blockquote>
47714
47715 <p>
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.
47719 </p>
47720
47721 <p>
47722 IMO, this is a serious design mistake for a couple of reasons:
47723 </p>
47724
47725 <ul>
47726 <li>
47727 <p>
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
47730 code.
47731 </p>
47732 <p>
47733 In fact, when I write the following simple function template:
47734 </p>
47735 <blockquote><pre>template &lt;typename T&gt;
47736 void doEmplace (T&amp; cont)
47737 {
47738    cont.emplace(cont.begin(),"nico","josuttis",42);
47739 }
47740 </pre></blockquote>
47741 <p>
47742 the semantics depends on the type of the container.
47743 </p>
47744 </li>
47745 <li>
47746 <p>
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>.
47752 </p>
47753 <p>
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.
47757 </p>
47758 </li>
47759 </ul>
47760
47761 <p>
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.
47764 </p>
47765
47766 <p>
47767 However, we have two choices for a fix:
47768 </p>
47769
47770 <ul>
47771 <li>
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).
47776 </li>
47777 <li>
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.
47782 </li>
47783 </ul>
47784
47785 <p><i>[
47786 2010 Pittsburgh:  Moved to NAD, rationale added below.
47787 ]</i></p>
47788
47789
47790
47791
47792 <p><b>Rationale:</b></p>
47793 <p>
47794 There was no consensus to make this change.
47795 </p>
47796
47797
47798 <p><b>Proposed resolution:</b></p>
47799 <p> In 23.2.5 [unord.req], change: </p>
47800 <blockquote> 
47801   <table border="1">
47802     <caption>Table 96 \97 Associative container requirements (in addition to 
47803     container)</caption>
47804     <tbody><tr> 
47805       <th>expression</th>
47806       <th>Return type</th>
47807       <th>Assertion/note pre-/post-condition</th>
47808       <th>Post-condition</th>
47809     </tr>
47810     <tr> 
47811       <td colspan="4">...</td>
47812     </tr>
47813     <tr> 
47814       <td><tt>a_uniq.emplace<ins>_value</ins>(args)</tt></td>
47815       <td><tt>pair&lt;iterator, bool&gt;</tt></td>
47816       <td>inserts a T object t constructed with std::forward&lt;Args&gt;(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>
47823     </tr>
47824     <tr> 
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&lt;Args&gt;(args)... 
47828         and returns the iterator pointing to the newly inserted element.</td>
47829       <td>logarithmic</td>
47830     </tr>
47831     <tr> 
47832       <td><tt>a.emplace<del>_hint</del>(p,args)</tt></td>
47833       <td><tt>iterator</tt></td>
47834       <td>equivalent to
47835       <tt>a.emplace<ins>_value</ins>(std::forward&lt;Args&gt;(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>
47841     </tr>
47842     <tr> 
47843       <td colspan="4">... </td>
47844     </tr>
47845   </tbody></table>
47846   
47847 </blockquote>
47848 <p> In 23.2.5 [unord.req], change: </p>
47849 <blockquote>
47850   <table border="1">
47851     <caption>Table 98 \97 Unordered associative container requirements (in 
47852     addition to container)</caption>
47853     <tbody><tr> 
47854       <th>expression</th>
47855       <th>Return type</th>
47856       <th>Assertion/note pre-/post-condition</th>
47857       <th>Post-condition</th>
47858     </tr>
47859     <tr> 
47860       <td colspan="4">...</td>
47861     </tr>
47862     <tr> 
47863       <td><tt>a_uniq.emplace<ins>_value</ins>(args)</tt></td>
47864       <td><tt>pair&lt;iterator, bool&gt;</tt></td>
47865       <td>inserts a <tt>T</tt> object <tt>t</tt> constructed with <tt>std::forward&lt;Args&gt;(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>
47871     </tr>
47872     <tr> 
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&lt;Args&gt;(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>
47878     </tr>
47879     <tr> 
47880       <td><tt>a.emplace<del>_hint</del>(p,args)</tt></td>
47881       <td><tt>iterator</tt></td>
47882       <td>equivalent to
47883       <tt>a.emplace<ins>_value</ins>(std::forward&lt;Args&gt;(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
47888       O(a.size()).</td>
47889     </tr>
47890     <tr> 
47891       <td colspan="4">... </td>
47892     </tr>
47893   </tbody></table>
47894 </blockquote>
47895
47896 <p>
47897 In 23.6.1 [map], 23.6.3 [set], 23.7.1 [unord.map], 23.7.3 [unord.set], change:
47898 </p>
47899 <blockquote> 
47900   <p><i>// modifiers:</i><br>
47901     <tt>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace<ins>_value</ins>(Args&amp;&amp;... 
47902     args);<br>
47903     template &lt;class... Args&gt; iterator emplace<del>_hint</del>(const_iterator 
47904     position, Args&amp;&amp;... args);</tt></p>
47905 </blockquote>
47906
47907 <p>
47908 In 23.6.2 [multimap], 23.6.4 [multiset], 23.7.2 [unord.multimap], 23.7.4 [unord.multiset], change:
47909 </p>
47910 <blockquote> 
47911   <p><i>// modifiers:<br></i><tt>template &lt;class... Args&gt; iterator emplace<ins>_value</ins>(Args&amp;&amp;... 
47912     args);<br>
47913     template &lt;class... Args&gt; iterator emplace<del>_hint</del>(const_iterator position, 
47914     Args&amp;&amp;... args);<br>
47915     </tt> </p>
47916 </blockquote>
47917
47918
47919
47920
47921
47922 <hr>
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>
47929
47930 <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>.
47937 </p>
47938
47939 <p><i>[
47940 2010-01-28 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
47941 ]</i></p>
47942
47943
47944 <p><i>[
47945 2010 Pittsburgh:
47946 ]</i></p>
47947
47948
47949 <blockquote>
47950 Moved to NAD Editorial.  Rationale added below.
47951 </blockquote>
47952
47953
47954
47955 <p><b>Rationale:</b></p>
47956 <p>
47957 Solved by N3058.
47958 </p>
47959
47960
47961 <p><b>Proposed resolution:</b></p>
47962 <p>
47963 Insert the following extra paragraphs:
47964 </p>
47965
47966 <p>
47967 In 30.6.7 [futures.shared_future]
47968 </p>
47969
47970 <blockquote><pre>shared_future();
47971 </pre>
47972 <blockquote>
47973 <p>
47974 4 <i>Effects:</i> constructs ...
47975 </p>
47976
47977 <p><ins>
47978 <i>Postcondition:</i> <tt>valid() == false</tt>.
47979 </ins></p>
47980
47981 <p><ins>
47982 <i>Throws:</i> nothing.
47983 </ins></p>
47984 </blockquote>
47985 </blockquote>
47986
47987 <blockquote><pre>void wait() const;
47988 </pre>
47989 <blockquote>
47990
47991 <p><ins>
47992 <i>Requires:</i> <tt>valid() == true</tt>.
47993 </ins></p>
47994
47995 <p>
47996 22 <i>Effects:</i> if the associated ...
47997 </p>
47998 </blockquote>
47999 </blockquote>
48000
48001 <blockquote><pre>template &lt;class Rep, class Period&gt;
48002   bool wait_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) const;
48003 </pre>
48004 <blockquote>
48005
48006 <p><ins>
48007 <i>Requires:</i> <tt>valid() == true</tt>.
48008 </ins></p>
48009
48010 <p>
48011 23 <i>Effects:</i> if the associated ...
48012 </p>
48013 </blockquote>
48014 </blockquote>
48015
48016 <blockquote><pre>template &lt;class Clock, class Duration&gt;
48017   bool wait_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) const;
48018 </pre>
48019 <blockquote>
48020
48021 <p><ins>
48022 <i>Requires:</i> <tt>valid() == true</tt>.
48023 </ins></p>
48024
48025 <p>
48026 25 <i>Effects:</i> blocks until ...
48027 </p>
48028 </blockquote>
48029 </blockquote>
48030
48031
48032
48033
48034
48035
48036 <hr>
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>
48043
48044 <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.  
48049 </p>
48050
48051 <p>
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
48058 <tt>is_ready</tt>.
48059 </p>
48060
48061 <p><i>[
48062 2010-01-23 See discussion starting with Message c++std-lib-26666.
48063 ]</i></p>
48064
48065
48066 <p><i>[
48067 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
48068 ]</i></p>
48069
48070
48071
48072
48073 <p><b>Rationale:</b></p>
48074 <p>
48075 Solved by
48076 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3058.html">N3058</a>.
48077 </p>
48078
48079
48080 <p><b>Proposed resolution:</b></p>
48081 <p>
48082 Insert the following extra paragraphs:
48083 </p>
48084
48085 <p>
48086 In 30.6.8 [futures.atomic_future]
48087 </p>
48088
48089 <blockquote><pre>bool is_ready() const;
48090 </pre>
48091 <blockquote>
48092 <p>
48093 17 <i><del>Precondition</del> <ins>Requires</ins>:</i> <tt>valid() == true</tt>.
48094 </p>
48095
48096 <p>
48097 18 <i>Returns:</i> <tt>true</tt> only if the associated state is ready.
48098 </p>
48099
48100 <p><ins>
48101 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48102 <tt>no_state</tt> if the precondition is not met.
48103 </ins></p>
48104
48105 </blockquote>
48106 </blockquote>
48107
48108 <blockquote><pre>bool has_exception() const;
48109 </pre>
48110 <blockquote>
48111
48112 <p><ins>
48113 <i>Requires:</i> <tt>valid() == true</tt>.
48114 </ins></p>
48115
48116 <p>
48117 19 <i>Returns:</i> <tt>true</tt> only if the associated state is ready and
48118 contains an exception.
48119 </p>
48120
48121 <p><ins>
48122 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48123 <tt>no_state</tt> if the precondition is not met.
48124 </ins></p>
48125
48126 </blockquote>
48127 </blockquote>
48128
48129 <blockquote><pre>bool has_value() const;
48130 </pre>
48131 <blockquote>
48132
48133 <p><ins>
48134 <i>Requires:</i> <tt>valid() == true</tt>.
48135 </ins></p>
48136
48137 <p>
48138 20 <i>Returns:</i> <tt>true</tt> only if the associated state is ready and
48139 contains a value.
48140 </p>
48141
48142 <p><ins>
48143 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48144 <tt>no_state</tt> if the precondition is not met.
48145 </ins></p>
48146
48147 </blockquote>
48148 </blockquote>
48149
48150 <blockquote><pre>void wait() const;
48151 </pre>
48152 <blockquote>
48153
48154 <p><ins>
48155 <i>Requires:</i> <tt>valid() == true</tt>.
48156 </ins></p>
48157
48158 <p>
48159 22 <i>Effects:</i> blocks until ...
48160 </p>
48161
48162 <p><ins>
48163 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48164 <tt>no_state</tt> if the precondition is not met.
48165 </ins></p>
48166
48167 </blockquote>
48168 </blockquote>
48169
48170 <blockquote><pre>template &lt;class Rep, class Period&gt;
48171   bool wait_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time) const;
48172 </pre>
48173 <blockquote>
48174
48175 <p><ins>
48176 <i>Requires:</i> <tt>valid() == true</tt>.
48177 </ins></p>
48178
48179 <p>
48180 23 <i>Effects:</i> blocks until ...
48181 </p>
48182
48183 <p>
48184 24 <i>Returns:</i> <tt>true</tt> only if ...
48185 </p>
48186
48187 <p><ins>
48188 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48189 <tt>no_state</tt> if the precondition is not met.
48190 </ins></p>
48191
48192 </blockquote>
48193 </blockquote>
48194
48195 <blockquote><pre>template &lt;class Clock, class Duration&gt;
48196   bool wait_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time) const;
48197 </pre>
48198 <blockquote>
48199
48200 <p><ins>
48201 <i>Requires:</i> <tt>valid() == true</tt>.
48202 </ins></p>
48203
48204 <p>
48205 25 <i>Effects:</i> blocks until ...
48206 </p>
48207
48208 <p>
48209 26 <i>Returns:</i> <tt>true</tt> only if ...
48210 </p>
48211
48212 <p><ins>
48213 <i>Throws:</i> <tt>future_error</tt> with an error condition of
48214 <tt>no_state</tt> if the precondition is not met.
48215 </ins></p>
48216
48217 </blockquote>
48218 </blockquote>
48219
48220
48221
48222
48223
48224
48225 <hr>
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>
48233 <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&lt;T&gt;</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&lt;T&gt;</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>).
48245 </p>
48246 <p>
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
48249 consequences:
48250 </p>
48251
48252 <ol>
48253 <li>
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&lt;T&gt;</tt>.
48257 </li>
48258 <li>
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.)
48261 </li>
48262 <li>
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&amp; c1 = min(a,b);</tt> and
48265 <tt>const T&amp; c2 = min({a,b});</tt> (<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&msg=25265">c++std-lib-25265</a>)
48266 </li>
48267 <li>
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.
48270 </li>
48271 <li>
48272 They potentially perform badly: possibly <i>O(n)</i>, when the arguments
48273 themselves have a size of <i>n</i>.
48274 </li>
48275 </ol>
48276
48277 <p>
48278 In the future, this problem might be solvable by using an
48279 <tt>initializer_list</tt> of <i>const references</i>, instead:
48280 </p>
48281 <blockquote><pre>const T&amp; min(initializer_list&lt;const T&amp;&gt;);
48282 const T&amp; max(initializer_list&lt;const T&amp;&gt;);
48283 pair&lt;const T&amp;, const T&amp;&gt; minmax(initializer_list&lt;const T&amp;&gt;);
48284 </pre></blockquote>
48285
48286 <p>
48287 It is unlikely that C++0x will support <tt>initializer_list&lt;const
48288 T&amp;&gt;</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>).
48290 </p>
48291 <p>
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>
48295 overloads:
48296 </p>
48297 <ol>
48298 <li>
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.
48302 </li>
48303 <li>
48304 They provide complete compile-time protection against accidentally passing zero
48305 arguments.
48306 </li>
48307 </ol>
48308
48309 <p>
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.
48315 </p>
48316
48317 <p><i>[
48318 2010 Pittsburgh:  Discussed and the LWG still prefers the initializer list
48319 solution of
48320 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>.
48321 ]</i></p>
48322
48323
48324
48325
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.
48330
48331
48332 <p><b>Proposed resolution:</b></p>
48333 <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].
48337 </p>
48338
48339 <blockquote>
48340 <p><i>[
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.
48342 ]</i></p>
48343
48344 </blockquote>
48345
48346
48347
48348
48349
48350 <hr>
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>
48357 <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
48360 sequence:
48361 </p>
48362
48363 <blockquote><pre>template&lt; typename ForwardIterator&gt;
48364 struct bad_iterator {
48365   shared_ptr&lt;ForwardIterator&gt; impl;
48366
48367   bad_iterator( ForwardIterator iter ) {
48368      : impl{new ForwardIterator{iter} } 
48369      {
48370   }
48371
48372   auto operator*() const -&gt; decltype(*ForwardIterator{}) {
48373      return **impl;
48374   }
48375
48376   auto operator-&gt;() const -&gt; ForwardIterator {
48377      return *impl;
48378   }
48379
48380   auto operator==(bad_iterator const &amp; rhs) {
48381      return impl == rhs.impl;
48382   }
48383
48384   auto operator++() {
48385      ++(*imp);
48386   }
48387   // other operations as necessary...
48388 };
48389 </pre></blockquote>
48390
48391 <p>
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.
48395 </p>
48396
48397 <p>
48398 There is a missing guarantee, expressed by the following code sequence
48399 </p>
48400
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>
48409
48410 <p>
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>(&amp;*x == &amp;*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>.
48416 </p>
48417
48418 <p>
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.
48422 </p>
48423
48424 <p>
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.
48427 </p>
48428
48429 <p><i>[
48430 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
48431 ]</i></p>
48432
48433
48434
48435
48436 <p><b>Rationale:</b></p>
48437 <p>
48438 Solved by
48439 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
48440 </p>
48441
48442
48443 <p><b>Proposed resolution:</b></p>
48444
48445
48446
48447
48448
48449 <hr>
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>
48456 <p>
48457 The Seed sequence requirements (26.5.1.2 [rand.req.seedseq]) require the
48458 existence of a member function
48459 </p>
48460
48461 <blockquote><pre>template&lt;typename OutputIterator&gt;
48462 void param(OutputIterator ob);
48463 </pre></blockquote>
48464
48465 <p>
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.
48470 </p>
48471
48472 <p><i>[
48473 2010-02-07 Howard adds:
48474 ]</i></p>
48475
48476
48477 <blockquote>
48478 At the time this issue was opened, the suggested changes are with respect to an
48479 anticipated draft which does not yet exist.
48480 </blockquote>
48481
48482 <p><i>[
48483 2010 Pittsburgh:
48484 ]</i></p>
48485
48486
48487 <blockquote>
48488 No technical counterarguments, but it is simply too late in the process
48489 to make this change at this point.
48490 </blockquote>
48491
48492
48493 <p><b>Proposed resolution:</b></p>
48494 <ol>
48495 <li>
48496 <p>
48497 In Table 109 \97 Seed sequence requirements, expression "<tt>r.param(ob)</tt>"
48498 change the<br>
48499 Return type entry:
48500 </p>
48501
48502 <blockquote><pre><del>void</del><ins>OutputIterator</ins>
48503 </pre></blockquote>
48504 </li>
48505
48506 <li>
48507 <p>
48508 In 26.5.7.1 [rand.util.seedseq], class seed_seq synopsis change
48509 </p>
48510
48511 <blockquote><pre>template&lt;class OutputIterator&gt;
48512 <del>void</del><ins>OutputIterator</ins> param(OutputIterator dest) const;
48513 </pre></blockquote>
48514 </li>
48515
48516 </ol>
48517
48518
48519
48520
48521
48522
48523 <hr>
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>
48530 <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:
48536 </p>
48537
48538 <blockquote><pre>void f(void*);
48539 void f(int);
48540
48541 void g()
48542 {
48543  // calls f(int) if NULL is integral
48544  // calls f(void*) if NULL is nullptr
48545  f(NULL);
48546 }
48547 </pre></blockquote>
48548
48549 <p>
48550 Possible resolutions:
48551 </p>
48552 <ul>
48553 <li>
48554 Forbid <tt>NULL</tt> from being <tt>nullptr</tt>
48555 </li>
48556 <li>
48557 Require <tt>NULL</tt> to be <tt>nullptr</tt>
48558 </li>
48559 <li>
48560 Leave it as is
48561 </li>
48562 </ul>
48563
48564 <p>
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.
48568 </p>
48569
48570 <p><i>[
48571 2010-02-10  Chris provided wording.
48572 ]</i></p>
48573
48574
48575 <p><i>[
48576 2010 Pittsburgh:  Moved to NAD, rationale added below.
48577 ]</i></p>
48578
48579
48580
48581
48582 <p><b>Rationale:</b></p>
48583 <p>
48584 The LWG discussed the proposed resolution and several other options.  There was
48585 no concensus to make this or any other changes.
48586 </p>
48587
48588
48589 <p><b>Proposed resolution:</b></p>
48590 <p>
48591 18.2 [support.types]
48592 </p>
48593
48594 <blockquote>
48595 <p>
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>
48599 </p>
48600
48601 <p><del>
48602 196) Possible definitions include <tt>0</tt> and <tt>0L</tt>, but not
48603 <tt>(void*)0</tt>.
48604 </del></p>
48605 </blockquote>
48606
48607 <p>
48608 20.9.13 [c.malloc]
48609 </p>
48610
48611 <blockquote>
48612 7 The contents are the same as the Standard C library header
48613 <tt>&lt;string.h&gt;</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>.
48615 </blockquote>
48616
48617
48618 <p>
48619 20.12 [date.time]
48620 </p>
48621
48622 <blockquote>
48623 2 The contents are the same as the Standard C library header
48624 <tt>&lt;time.h&gt;</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).
48628 </blockquote>
48629
48630
48631 <p>
48632 22.6 [c.locales]
48633 </p>
48634
48635 <blockquote>
48636 2 The contents are the same as the Standard C library header
48637 <tt>&lt;locale.h&gt;</tt> <ins>except the macro <tt>NULL</tt>, which is defined
48638 to be <tt>nullptr</tt></ins>.
48639 </blockquote>
48640
48641 <p>
48642 C.2.2.4 [diff.null]
48643 </p>
48644
48645 <blockquote>
48646 1 The macro <tt>NULL</tt>, defined in any of <tt>&lt;clocale&gt;</tt>,
48647 <tt>&lt;cstddef&gt;</tt>, <tt>&lt;cstdio&gt;</tt>, <tt>&lt;cstdlib&gt;</tt>,
48648 <tt>&lt;cstring&gt;</tt>, <tt>&lt;ctime&gt;</tt>, or <tt>&lt;cwchar&gt;</tt>, is
48649 <ins>nullptr</ins> <del>an implementation-defined C++ null pointer constant in
48650 this International Standard (18.2).</del>
48651 </blockquote>
48652
48653
48654
48655
48656
48657
48658 <hr>
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>
48665 <p>
48666 Both overloads of <tt>async</tt> return <tt>future&lt;typename
48667 F::result_type&gt;</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.
48670 </p>
48671
48672 <p>
48673 The proposed resolution also addresses editorial issues with the
48674 <tt>launch_policy</tt> function parameter.
48675 </p>
48676
48677 <p>
48678 For the first overload it is not sufficient to return <tt>future&lt;typename
48679 result_of&lt;F(ArgTypes...)&gt;::type&gt;</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&lt;launch(F,
48682 ArgTypes...)&gt;</tt>, which is invalid. SFINAE must be used to prevent that.
48683 </p>
48684
48685 <p><i>[
48686 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
48687 ]</i></p>
48688
48689
48690 <p><i>[
48691 2010-02-12 Daniel opens:
48692 ]</i></p>
48693
48694
48695 <blockquote>
48696 <p>
48697 [..] if <tt>decay&lt;F&gt;::type</tt> is of type <tt>std::launch</tt>.
48698 </p>
48699 <p>
48700 or
48701 </p>
48702 <p>
48703 [..] if <tt>remove_cv&lt;remove_reference&lt;F&gt;::type&gt;::type</tt> is of
48704 type <tt>std::launch</tt>.
48705 </p>
48706
48707 <p>
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
48711 use the latter.
48712
48713 </p>
48714 </blockquote>
48715
48716 <p><i>[
48717 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
48718 ]</i></p>
48719
48720
48721 <p><i>[
48722 2010 Pittsburgh:
48723 ]</i></p>
48724
48725
48726 <blockquote>
48727 Moved to NAD Editorial.  Rationale added below.
48728 </blockquote>
48729
48730
48731
48732 <p><b>Rationale:</b></p>
48733 <p>
48734 Solved by N3058.
48735 </p>
48736
48737
48738 <p><b>Proposed resolution:</b></p>
48739 <p>
48740 In 30.6.1 [futures.overview] paragraph 1:
48741 </p>
48742
48743 <blockquote><pre>template &lt;class F, class... Args&gt;
48744   <del>future&lt;typename F::result_type&gt;</del>
48745   <ins>future&lt;typename result_of&lt;F(Args...)&gt;::type&gt;</ins>
48746   async(F&amp;&amp; f, Args&amp;&amp;... args);
48747 template &lt;class F, class... Args&gt;
48748   <del>future&lt;typename F::result_type&gt;</del>
48749   <ins>future&lt;typename result_of&lt;F(Args...)&gt;::type&gt;</ins>
48750   async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
48751 </pre></blockquote>
48752
48753 <p>
48754 In 30.6.9 [futures.async] before paragraph 1
48755 </p>
48756
48757 <blockquote><pre>template &lt;class F, class... Args&gt;
48758   <del>future&lt;typename F::result_type&gt;</del>
48759   <ins>future&lt;typename result_of&lt;F(Args...)&gt;::type&gt;</ins>
48760   async(F&amp;&amp; f, Args&amp;&amp;... args);
48761 template &lt;class F, class... Args&gt;
48762   <del>future&lt;typename F::result_type&gt;</del>
48763   <ins>future&lt;typename result_of&lt;F(Args...)&gt;::type&gt;</ins>
48764   async(launch policy, F&amp;&amp; f, Args&amp;&amp;... args);
48765 </pre>
48766 <blockquote>
48767 <p>...</p>
48768 <p><ins>
48769 <i>Remarks:</i> The first signature shall not participate in overload resolution
48770 if <tt>decay&lt;F&gt;::type</tt> is <tt>std::launch</tt>.
48771 </ins></p>
48772 </blockquote>
48773 </blockquote>
48774
48775
48776
48777
48778
48779
48780 <hr>
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>
48787 <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.
48791 </p>
48792
48793 <p>
48794 While we can easily declare an
48795 </p>
48796
48797 <blockquote><pre>std::unordered_set&lt;int&gt;
48798 </pre></blockquote>
48799
48800 <p>
48801 or
48802 </p>
48803
48804 <blockquote><pre>std::unordered_set&lt;std::string&gt;
48805 </pre></blockquote>
48806
48807 <p>
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.
48812 </p>
48813
48814 <p>
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.
48817 </p>
48818
48819 <p>
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
48822 state of C++0x.
48823 </p>
48824
48825 <p>
48826 However, I strongly suggest at least to provide a convenience variadic template
48827 function <tt>make_hash&lt;&gt;()</tt> to allow an easy definition of a (possibly
48828 poor) hash function.
48829 </p>
48830
48831 <p>
48832 As a consequence for a user-defined type such as
48833 </p>
48834
48835 <blockquote><pre>class Customer {
48836    friend class CustomerHash;
48837    private:
48838      string firstname;
48839      string lastname;
48840      long   no;
48841    ...
48842  };
48843 </pre></blockquote>
48844
48845 <p>
48846 would allow to specify:
48847 </p>
48848
48849 <blockquote><pre>class CustomerHash : public std::unary_function&lt;Customer, std::size_t&gt;
48850 {
48851   public:
48852     std::size_t operator() (const Customer&amp; c) const  {
48853        return make_hash(c.firstname,c.lastname,c.no);
48854     }
48855 };
48856 </pre></blockquote>
48857
48858 <p>
48859 instead of:
48860 </p>
48861
48862 <blockquote><pre>class CustomerHash : public std::unary_function&lt;Customer, std::size_t&gt;
48863 {
48864   public:
48865     std::size_t operator() (const Customer&amp; c) const  {
48866        return std::hash&lt;std::string&gt;()(c.firstname) +
48867               std::hash&lt;std::string&gt;()(c.lastname) +
48868               std::hash&lt;long&gt;()(c.no);
48869     }
48870 };
48871 </pre></blockquote>
48872
48873 <p>
48874 Note that, in principle, we can either specify that
48875 </p>
48876
48877 <blockquote>
48878 <tt>make_hash</tt> returns the sum of a call of
48879 <tt>std::hash&lt;T&gt;()(x)</tt> for each argument <tt>x</tt> of type
48880 <tt>T</tt>
48881 </blockquote>
48882
48883 <p>
48884 or we can specify that
48885 </p>
48886
48887 <blockquote>
48888 <tt>make_hash</tt> provides a hash value for each argument, for which a
48889 <tt>std::hash()</tt> function is provided
48890 </blockquote>
48891
48892 <p>
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.
48895 </p>
48896
48897 <p>
48898 For my convenience, I propose wording that describes
48899 the concrete implementation.
48900 </p>
48901
48902 <p><i>[
48903 2010 Pittsburgh:  Moved to NAD Editorial, rationale added below.
48904 ]</i></p>
48905
48906
48907
48908
48909 <p><b>Rationale:</b></p>
48910 <p>
48911 There is no consensus to make this change at this time.
48912 </p>
48913
48914
48915 <p><b>Proposed resolution:</b></p>
48916 <p>
48917 In Function objects 20.8 [function.objects]
48918 in paragraph 2 at the end of the Header <tt>&lt;functional&gt;</tt> synopsis
48919 insert:
48920 </p>
48921
48922 <blockquote><pre>// convenience functions
48923 template &lt;class T&gt;
48924   size_t make_hash (const T&amp;);
48925 template &lt;class T, class... Types&gt;
48926   size_t make_hash (const T&amp;, const Types&amp;...);
48927 </pre></blockquote>
48928
48929 <p>
48930 In Class template hash 20.8.15 [unord.hash]
48931 add:
48932 </p>
48933
48934 <blockquote>
48935 <p>
48936 <b>20.7.16.1 Hash creation functions [hash.creation]</b>
48937 </p>
48938
48939 <pre>template &lt;class T&gt;
48940   size_t make_hash (const T&amp; val);
48941 </pre>
48942
48943 <blockquote>
48944 <i>Returns:</i> <tt>hash&lt;T&gt;()(val);</tt>
48945 </blockquote>
48946
48947 <pre>template &lt;class T, class... Types&gt;
48948   size_t make_hash (const T&amp; val, const Types&amp;... args);
48949 </pre>
48950
48951 <blockquote>
48952 <i>Returns:</i> <tt>hash&lt;T&gt;()(val) + std::make_hash(args...)</tt>
48953 </blockquote>
48954
48955 </blockquote>
48956
48957
48958
48959
48960
48961
48962 <hr>
48963 <h3><a name="1329"></a>1329. Data races on <code>vector&lt;bool&gt;</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>
48968 <p>
48969 The common implementation of <tt>vector&lt;bool&gt;</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.
48973 </p>
48974
48975 <p><i>[
48976 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
48977 ]</i></p>
48978
48979
48980
48981
48982 <p><b>Rationale:</b></p>
48983 <p>
48984 Solved by
48985 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3069.html">N3069</a>.
48986 </p>
48987
48988
48989 <p><b>Proposed resolution:</b></p>
48990 <p>
48991 Container data races 23.2.2 [container.requirements.dataraces]
48992 </p>
48993
48994 <p>
48995 Paragraph 1 is unchanged as follows:
48996 </p>
48997
48998 <blockquote>
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>.
49006 </blockquote>
49007
49008 <p>
49009 Edit paragraph 2 as follows:
49010 </p>
49011
49012 <blockquote>
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&lt;bool&gt;</code>,</ins>
49016 are modified concurrently.
49017 </blockquote>
49018
49019 <p>
49020 Edit paragraph 3 as follows:
49021 </p>
49022
49023 <blockquote>
49024 3 [<i>Note:</i>
49025 For a <code>vector&lt;int&gt; 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&lt;bool&gt; y</code>,
49032 <code>y[i] = true</code> may race with <code>y[j] = true</code>.</ins>
49033 \97<i>end note</i>]
49034 </blockquote>
49035
49036
49037
49038
49039
49040
49041 <hr>
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>
49049 <p>
49050 Review the library portion of the spec and incorporate the newly added
49051 core feature Move Special Member Functions (N3044).
49052 </p>
49053
49054 <p><b>Rationale:</b></p>
49055 2010 Batavia: This has now been done to a large extent.
49056
49057
49058
49059
49060 <p><b>Proposed resolution:</b></p>
49061
49062
49063
49064
49065
49066 <hr>
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>
49076 <p>
49077 Due to the new rules about implicit copy and move
49078 constructors some library facilities are now move-only.
49079 </p>
49080
49081 <p><i>[
49082 Resolution proposed by ballot comment
49083 ]</i></p>
49084
49085 <p>
49086 Make them copyable again.
49087 </p>
49088
49089
49090 <p><b>Proposed resolution:</b></p>
49091
49092
49093
49094
49095
49096 <hr>
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>
49105
49106 <p><b>Addresses CH-16</b></p>
49107 <p>
49108 Dynamic exception specifications are deprecated.
49109 Deprecated features shouldn't be used in the Standard.
49110 </p>
49111
49112 <p><i>[
49113 Resolution proposed by ballot comment
49114 ]</i></p>
49115
49116 <p>
49117 Replace dynamic exception specifications with <tt>noexcept</tt>.
49118 </p>
49119
49120
49121 <p><b>Proposed resolution:</b></p>
49122
49123
49124
49125
49126
49127 <hr>
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>
49136
49137 <p><b>Addresses CH-17</b></p>
49138 <p>
49139 The introduction of <tt>noexcept</tt> makes "Throws: Nothing" clauses looking strange.
49140 </p>
49141
49142 <p><i>[
49143 Resolution proposed by ballot comment
49144 ]</i></p>
49145
49146 <p>
49147 Consider replacing "Throws: Nothing." clause by
49148 the respective noexcept specification.
49149 </p>
49150
49151
49152
49153 <p><b>Proposed resolution:</b></p>
49154
49155
49156
49157
49158
49159 <hr>
49160 <h3><a name="1359"></a>1359. [FCD] Add <tt>&lt;tuple&gt;</tt> and <tt>&lt;utility&gt;</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>
49167 <p>
49168 The <tt>&lt;utility&gt;</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>&lt;tuple&gt;</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.
49177 </p>
49178 <p>
49179 Alternatively, split the <tt>move</tt>/<tt>forward</tt>/<tt>swap</tt>/<tt>declval</tt>
49180 functions out of <tt>&lt;utility&gt;</tt> and into a new primitive header,
49181 requiring only that of freestanding implementation.
49182 </p>
49183
49184 <p><i>[
49185 Summary of Rapperswil discusions
49186 ]</i></p>
49187
49188 <p>
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>&lt;type_traits&gt;</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).
49190 </p>
49191
49192 <p>
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?
49194
49195 SF new header: 4 WF new header: 3 WF call out as freestanding: 1 SF call out as freestanding: 2
49196
49197 Alisdair: Willing to write up both solutions, give us some time to think on it.
49198
49199 Action: Need an issue and proposed wording for GB 56 - Alisdair to draft both options as in the last poll. 
49200 </p>
49201
49202 <p><i>[
49203 Resolution proposed by ballot comment
49204 ]</i></p>
49205
49206 <blockquote>
49207 <p>
49208 Add <tt>&lt;utility&gt;</tt> and <tt>&lt;tuple&gt;</tt> to table 15, headers
49209 required for a free-standing implementation.
49210 </p>
49211 </blockquote>
49212
49213 <p><i>[
49214 2010-Batavia:
49215 ]</i></p>
49216
49217 <p>
49218 Closed as NAD, reversing the decision at Rapperswil.
49219 </p>
49220 <p>
49221 The consensus was that
49222 any freestanding implementation is going to feel compelled to offer the important
49223 features of <tt>&lt;utility&gt;</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>&lt;type_traits&gt;</tt>, the header name is far from appealing; adding the
49227 whole of <tt>&lt;utility&gt;</tt> starts to drag in dependencies on <tt>&lt;tuple&gt;</tt>
49228 and <tt>&lt;memory&gt;</tt>, so we prefer to place the burden of slicing or supporting
49229 this whole header on free-standing vendors.
49230 </p>
49231
49232
49233
49234 <p><b>Proposed resolution:</b></p>
49235
49236
49237 <p><b>Rationale:</b></p>No consensus for a change at this time. 
49238
49239
49240
49241
49242
49243 <hr>
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>
49250 <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
49257 be accepted:
49258 </p>
49259 <blockquote><pre>#include &lt;vector&gt;
49260 std::size_t x = 0;
49261 </pre></blockquote>
49262 <p>
49263 Most often, this question concerns the typedefs defined in
49264 header <tt>&lt;cstddef&gt;</tt>
49265 </p>
49266
49267 <p><i>[
49268 Resolution proposed by ballot comment:
49269 ]</i></p>
49270
49271 <p>
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>&lt;cstddef&gt;</tt> must be included to reliably
49276 use this name.
49277 </p>
49278 <p><i>[Batavia: NAD - see rationale below]</i></p>
49279
49280
49281
49282
49283 <p><b>Proposed resolution:</b></p>
49284
49285 <p><b>Rationale:</b></p>The standard is correct as written.
49286
49287
49288
49289
49290 <hr>
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>
49298 <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.
49306 </p>
49307
49308 <p><i>[
49309 2010 Rapperswil
49310 ]</i></p>
49311
49312 <p>
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.
49316 </p>
49317
49318 <p><i>[
49319 2010 Rapperswil
49320 ]</i></p>
49321
49322 <p>
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.
49326 </p>
49327
49328 <p><i>[
49329 Resolution proposed in ballot comment
49330 ]</i></p>
49331
49332 <p>
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
49336 compatibility:
49337 </p>
49338 <blockquote><pre>iterator_traits (plus the iterator tag-types)
49339 allocator_traits
49340 pointer_traits
49341 char_traits
49342 regex_traits
49343 </pre></blockquote>
49344
49345 <p><i>[
49346 2010 Batavia:
49347 ]</i></p>
49348
49349 <p>
49350 Closed as NAD with the rationale below.
49351 </p>
49352
49353
49354
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.
49359
49360
49361 <p><b>Proposed resolution:</b></p>
49362
49363
49364
49365
49366
49367 <hr>
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>
49376
49377 <p><b>Addresses US-87</b></p>
49378 <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&amp;</tt>, it is an important customization point for
49382 extensions and future features.
49383 </p>
49384
49385
49386 <p><b>Proposed resolution:</b></p>
49387 <p>
49388 In [allocator.requirements] Table 42 - Allocotor Requirements, 
49389 Add a row (after <tt>value_type</tt>) with columns:
49390 </p>
49391 <blockquote>
49392 Expression: <ins><tt>X::reference_type</tt></ins><br>
49393 Return type: <ins><tt>T&amp;</tt></ins><br>
49394 Assertion/note...: (empty)<br>
49395 Default: <ins><tt>T&amp;</tt></ins><br>
49396 </blockquote>
49397 <p>
49398 [allocator.traits]:
49399 </p> 
49400 <blockquote><pre>namespace std {
49401   template &lt;class Alloc&gt; struct allocator_traits {
49402     typedef Alloc allocator_type;
49403     
49404     typedef typename Alloc::value_type value_type;
49405
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&amp; reference_type;</ins>
49411 </pre></blockquote>
49412
49413 Add <tt>reference_type</tt> to
49414 allocator_traits template, defaulted to
49415 value_type&amp;.
49416
49417
49418
49419
49420
49421 <hr>
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>
49429 <p>
49430 Allocator interface is not backward compatible.
49431 </p>
49432
49433 <p><i>[
49434 Resolution proposed by ballot comment
49435 ]</i></p>
49436
49437 <p>
49438 See Appendix 1 - Additional Details
49439 </p>
49440
49441 <p><i>[
49442 2010-10-24 Daniel adds:
49443 ]</i></p>
49444
49445
49446 <blockquote>
49447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3165.pdf">n3165</a> provides an alternative resolution.
49448 </blockquote>
49449
49450 <p><i>[
49451 2910 Batavia:
49452 ]</i></p>
49453
49454 <p>
49455 Closed as NAD - withdrawn by the submitter.
49456 </p>
49457
49458
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>
49461
49462
49463 <p><b>Rationale:</b></p>Withdrawn by the submitter.
49464
49465
49466
49467
49468 <hr>
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>
49476 <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
49485 number Z.
49486 </p>
49487
49488
49489 <p><b>Proposed resolution:</b></p>
49490 Change "(10)" to "(Clause 10)".
49491
49492
49493
49494
49495
49496 <hr>
49497 <h3><a name="1398"></a>1398. [FCD] Users should be able to specialize functors without depending on whole <tt>&lt;functional&gt;</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>
49504 <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>&lt;functional&gt;</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.
49514 </p>
49515
49516 <p><i>[
49517 Resolution proposed by ballot comment
49518 ]</i></p>
49519
49520 <p>
49521 Provide a tiny forwarding header for important
49522 functor types in the <tt>&lt;functional&gt;</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
49525 <tt>less</tt>.
49526 </p>
49527
49528 <p><i>[
49529 Rapperswill summary
49530 ]</i></p>
49531
49532 <p>Alisdair: Would recommend NAD unless someone takes the issue. </p>
49533
49534 <p>Daniel: Volunteers to write a paper for this. </p>
49535
49536 <p><i>[
49537 2010-11-07 Daniel provides a paper available on the Batavia document list
49538 ]</i></p>
49539
49540
49541 <p><i>[
49542 2010 Batavia:
49543 ]</i></p>
49544
49545 <p>
49546 Closed as NAD - the consensus was that forwarding headers such as
49547 <tt>&lt;iosfwd&gt;</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.
49551 </p>
49552
49553
49554
49555 <p><b>Rationale:</b></p>No consensus to make a change
49556
49557 <p><b>Proposed resolution:</b></p>
49558 See paper "Forwarding <tt>&lt;functional&gt;</tt> functor templates"
49559 on the Batavia LWG document list
49560
49561
49562
49563
49564
49565 <hr>
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>
49573 <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) &amp;&amp; !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&lt;U&gt;
49587 const &amp;, 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
49596 inconsistent.
49597 </p>
49598 <p>
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.
49608 </p>
49609 <p>
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.
49616 </p>
49617 <p>
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>.
49622 </p>
49623
49624 <p><i>[2010 Rapperswil:]</i></p>
49625
49626 <blockquote>
49627 <p>No consensus to make this change at this time.</p>
49628 </blockquote>
49629
49630
49631 <p><b>Proposed resolution:</b></p>
49632 <p>
49633 Add the following non-static member functions to
49634 <tt>shared_ptr</tt> and <tt>weak_ptr</tt> class template;
49635 </p>
49636 <p>
49637 Update [util.smartptr.shared], 20.9.11.2 paragraph 1
49638 </p>
49639 <pre>namespace std{
49640 template&lt;class T&gt; class shared_ptr {
49641 public:
49642 ...
49643   <ins>size_t owner_hash() const;</ins>
49644 ...
49645 };
49646 }
49647 </pre>
49648 <p>
49649 Update [util.smartptr.weak], 20.9.11.3 paragraph 1
49650 </p>
49651 <pre>namespace std{
49652 template&lt;class T&gt; class weak_ptr {
49653 public:
49654 ...
49655   <ins>size_t owner_hash() const;</ins>
49656 ...
49657 };
49658 }
49659 </pre>
49660 <p>
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.
49670 </p>
49671
49672
49673
49674
49675
49676 <hr>
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>
49684
49685 <p><b>Addresses DE-20</b></p>
49686
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>.)
49693
49694
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>.
49699
49700
49701
49702
49703
49704 <hr>
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.
49714
49715 <p><i>[
49716 Resolved in Rapperswil by paper N3108.
49717 ]</i></p>
49718
49719
49720
49721
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.
49729
49730
49731
49732
49733
49734 <hr>
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>
49742
49743 forward_list::erase_after should return an iterator.
49744
49745 <p><i>[
49746 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
49747 ]</i></p>
49748
49749
49750
49751
49752 <p><b>Proposed resolution:</b></p>
49753 See Appendix 1 - Additional Details
49754
49755
49756
49757
49758
49759 <hr>
49760 <h3><a name="1422"></a>1422. [FCD] vector&lt;bool&gt; 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>
49767 <p>
49768 <tt>vector&lt;bool&gt;</tt> iterators are not random access iterators
49769 because their reference type is a special class, and not
49770 <tt>bool &amp;</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.
49773 </p>
49774
49775 <p><i>[
49776 Resolution proposed in ballot comment
49777 ]</i></p>
49778
49779 <p>
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&lt;bool&gt;</tt>
49783 specification requiring the library to treat <tt>vector&lt;bool&gt;</tt>
49784 iterators as-if they were random access iterators, despite having the wrong
49785 reference type.
49786 </p>
49787
49788 <p><i>[
49789 Rapperswil Review
49790 ]</i></p>
49791
49792 <p>
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&amp;;t;bool&gt;</tt>
49795 iterators as-if they were random access would be preferable to flagging
49796 this container as deliberately incompatible with standard library algorithms.
49797 </p>
49798 <p>
49799 Alisdair to write the note, which may become normative <i>Remark</i> depending
49800 on the preferences of the project editor.
49801 </p>
49802
49803 <p><i>[
49804 Post-Rapperswil Alisdair provides wording
49805 ]</i></p>
49806
49807 <p>
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&lt;vector&lt;bool&gt;&gt;::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.
49813 </p>
49814
49815 <p><i>[
49816 Old Proposed Resolution:
49817 ]</i></p>
49818
49819 <blockquote>
49820 <p>
49821 Insert a new paragraph into 23.4.2 [vector.bool] between p4 and p5:
49822 </p>
49823 <blockquote>
49824 [<i>Note</i> All functions in the library that take a pair of iterators to
49825 denote a range shall treat <tt>vector&lt;bool&gt;</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>]
49828 </blockquote>
49829 </blockquote>
49830
49831 <p><i>[
49832 2010-11 Batavia:
49833 ]</i></p>
49834
49835 <blockquote>
49836 Closed as NAD Future, because the current iterator categories cannot correctly describe
49837 <tt>vector&lt;bool&gt;::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&lt;bool&gt;</tt> now.
49841 </blockquote>
49842
49843
49844
49845 <p><b>Proposed resolution:</b></p>
49846
49847
49848 <p><b>Rationale:</b></p>
49849 No consensus to make this change at this time.
49850
49851
49852
49853
49854
49855 <hr>
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>
49864
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
49871 consistently.
49872
49873
49874 <p><b>Proposed resolution:</b></p>
49875 [DEPENDS ON WHETHER RVALUE OR
49876 LVALUE REFERENCE IS THE PREFERRED
49877 FORM]
49878
49879
49880
49881
49882
49883 <hr>
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>
49891
49892 It was the LWG's intent in Pittsburgh that N2772 be
49893 applied to the WP.
49894
49895 <p><i>[
49896 Resolved in Rapperswil by paper N3106.
49897 ]</i></p>
49898
49899
49900
49901
49902 <p><b>Proposed resolution:</b></p>
49903 Apply N2772 to the WP.
49904
49905
49906
49907
49908
49909 <hr>
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>
49918
49919 <p><i>[CA-9:]</i></p>
49920
49921
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>
49927 27.2.3p2<br>
49928 30.3.1.2p6<br>
49929 30.3.1.5p7<br>
49930 30.6.4p7<br>
49931 30.6.9p5<br>
49932 30.6.10.1p23<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.
49939
49940 <p><i>[GB-122]</i></p>
49941
49942
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>
49946
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>
49951
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>
49962
49963 <p>27.2.3:2,
49964 30.3.1.2:6,
49965 30.3.1.5:7,
49966 30.6.4:7,
49967 30.6.9:5,
49968 30.6.10.1:23</p>
49969
49970 <p><b>Proposed resolution:</b></p>
49971
49972 <p><i>[Beman provided specific wording for the proposed resolution.]</i></p>
49973
49974
49975 <p>Change 27.2.3 Thread Safety [iostreams.threadsafety] paragraph 2:</p>
49976
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>
49978
49979 <p>Change 30.3.1.2 thread constructors [thread.thread.constr] paragraph 6:</p>
49980
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>
49982
49983 <p>Change 30.3.1.5 thread members [thread.thread.member] paragraph 7:</p>
49984
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>
49986
49987 <p>Change 30.6.4 Associated asynchronous state [futures.state] paragraph 7:</p>
49988
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>
49991
49992 <p>Change 30.6.9 Function template async [futures.async] paragraph 5:</p>
49993
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>
50003
50004 <p>Change 30.6.10.1 packaged_task member functions [futures.task.members] paragraph 23:</p>
50005
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>
50011
50012
50013
50014
50015
50016
50017 <hr>
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>
50025
50026
50027 <p><b>Addresses GB-122</b></p>
50028
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>
50032
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>
50037
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>
50048
50049 <p>27.2.3:2,
50050 30.3.1.2:6,
50051 30.3.1.5:7,
50052 30.6.4:7,
50053 30.6.9:5,
50054 30.6.10.1:23</p>
50055
50056
50057 <p><b>Proposed resolution:</b></p>
50058 Request the concurrency working group to
50059 determine if changes are needed
50060
50061
50062
50063
50064
50065 <hr>
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>
50073
50074 <p><b>Addresses GB-123</b></p>
50075
50076 Several rows in table 124 specify a Return type of
50077 'OFF_T', which does not appear to be a type defined in
50078 this standard.
50079
50080
50081 <p><b>Proposed resolution:</b></p>
50082 Resolve outstanding references to the removed
50083 type 'OFF_T'.
50084
50085
50086
50087
50088
50089 <hr>
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>
50097
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.
50105
50106 <p><i>[
50107 Resolution proposed by ballot comment:
50108 ]</i></p>
50109
50110 <p>
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
50120 </p>
50121
50122 <p><i>[
50123 2010-10-24 Daniel adds:
50124 ]</i></p>
50125
50126
50127 <blockquote>
50128 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3179.pdf">n3179</a> would solve this issue.
50129 </blockquote>
50130
50131 <p><i>[
50132 2010-11 Batavia
50133 ]</i></p>
50134
50135 <p>
50136 Closed as NAD.
50137 </p>
50138 <blockquote>
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.
50143 </blockquote>
50144
50145
50146
50147 <p><b>Proposed resolution:</b></p>
50148
50149
50150
50151
50152
50153 <hr>
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>
50161
50162 <p><b>Addresses US-141</b></p>
50163
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.
50168
50169
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.
50173
50174
50175
50176
50177
50178 <hr>
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>
50187
50188 <p><b>Addresses GB-128</b></p>
50189 <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)
50197 </p>
50198
50199
50200 <p><i>[
50201 Resolution proposed by ballot comment
50202 ]</i></p>
50203
50204 <p>
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.
50210 </p>
50211
50212
50213 <p><b>Proposed resolution:</b></p>
50214
50215
50216
50217
50218
50219 <hr>
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>
50227
50228 <p><b>Addresses GB-131</b></p>
50229
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
50236 sequence.
50237 </blockquote><p></p>
50238 <p>
50239 ... but 1.9 [intro.execution] p.13 states:
50240 </p>
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>
50246 <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.
50251 </p>
50252
50253
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]
50258
50259
50260
50261
50262
50263 <hr>
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>
50271
50272 <p><b>Addresses US-157</b></p>
50273
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.
50276
50277
50278 <p><b>Proposed resolution:</b></p>
50279 Add a non-volatile assignment operator to <tt>atomic_bool</tt>.
50280
50281
50282
50283
50284
50285 <hr>
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>
50295
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>
50300
50301
50302
50303 <p><b>Proposed resolution:</b></p>
50304
50305
50306
50307
50308
50309 <hr>
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>
50318
50319 29.6 [atomics.types.operations] around p. 4: The definition of the default constructor needs exposition.
50320
50321
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:
50324 <p>
50325 </p>
50326 <blockquote>
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>]
50331 </blockquote>
50332 <blockquote><pre><ins>A::A() = default;</ins>
50333 </pre><blockquote>
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);
50338 [..]
50339 </pre></blockquote>
50340
50341
50342
50343
50344
50345 <hr>
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>
50354
50355 As of 29.6 [atomics.types.operations] p. 7:
50356 <p>
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
50359 initialization.
50360
50361
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);
50366 </pre><blockquote>
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>
50372
50373
50374
50375
50376
50377 <hr>
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>
50386
50387 As of 29.6 [atomics.types.operations] p. 9, 13, 17, 20:
50388 <p>
50389 The order specifications are incomplete because the non-<tt>_explicit</tt>
50390 functions do not have such parameters.
50391 </p><p>
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>."
50396
50397
50398 </p><p><i>[
50399 2010 Batavia
50400 ]</i></p>
50401
50402 <p>
50403 The Concurrency subgroup reviewed this, and deemed it NAD according to
50404 29.6 [atomics.types.operations] paragraph 2, bullet 4. 
50405 </p>
50406
50407 <p><b>Rationale:</b></p>The working paper is correct as written.
50408
50409
50410
50411 <p><b>Proposed resolution:</b></p>
50412 <ol>
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);
50420 </pre><blockquote>
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>.
50423 <p>
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>
50428 </li>
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;
50436 </pre><blockquote>
50437 12 <em>Requires</em>: The order argument shall not be <tt>memory_order_release</tt> nor <tt>memory_order_acq_rel</tt>.
50438 <p>
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>
50441 </p><p>
50442 14 <em>Returns</em>: Atomically returns the value pointed to by <tt>object</tt> or by <tt>this</tt>.
50443 </p></blockquote></blockquote>
50444 </li>
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);
50452 </pre><blockquote>
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>
50456 <p>
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>
50459 </li>
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 &amp; expected, C desired,
50474   memory_order success, memory_order failure) volatile;
50475 bool A::compare_exchange_weak(C &amp; expected, C desired,
50476   memory_order success, memory_order failure);
50477 bool A::compare_exchange_strong(C &amp; expected, C desired,
50478   memory_order success, memory_order failure) volatile;
50479 bool A::compare_exchange_strong(C &amp; expected, C desired,
50480   memory_order success, memory_order failure);
50481 bool A::compare_exchange_weak(C &amp; expected, C desired,
50482   memory_order order = memory_order_seq_cst) volatile;
50483 bool A::compare_exchange_weak(C &amp; expected, C desired,
50484   memory_order order = memory_order_seq_cst);
50485 bool A::compare_exchange_strong(C &amp; expected, C desired,
50486   memory_order order = memory_order_seq_cst) volatile;
50487 bool A::compare_exchange_strong(C &amp; expected, C desired,
50488   memory_order order = memory_order_seq_cst);
50489 </pre><blockquote>
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.
50492 <p>
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.
50504 </p><p>
50505 [..]
50506 </p></blockquote></blockquote>
50507 </li>
50508 </ol>
50509
50510
50511
50512
50513
50514 <hr>
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>
50524
50525 29.6 [atomics.types.operations] p. 23: The first sentence has non-English syntax.
50526
50527 <p><i>[
50528 Resolution proposed in ballot comment:
50529 ]</i></p>
50530
50531
50532 <p>
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."
50537 </p>
50538
50539
50540 <p><b>Proposed resolution:</b></p>
50541
50542
50543
50544
50545
50546 <hr>
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>
50555
50556 <p><b>Addresses US-177</b></p>
50557
50558 The first sentence of this paragraph doesn't make sense.
50559
50560 <p><i>[
50561 Resolution proposed in ballot comment
50562 ]</i></p>
50563
50564 <p>
50565 Figure out what it's supposed to say, and say it.
50566 </p>
50567
50568
50569 <p><b>Proposed resolution:</b></p>
50570
50571
50572
50573
50574
50575 <hr>
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>
50585
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.
50597
50598 <p><i>[
50599 Resolution proposed in ballot comment:
50600 ]</i></p>
50601
50602 <p>
50603 Fix the Remark to say whatever was intended.
50604 </p>
50605
50606
50607
50608 <p><b>Proposed resolution:</b></p>
50609
50610
50611
50612
50613
50614 <hr>
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>
50621
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.
50625
50626 <p><i>[
50627 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50628 ]</i></p>
50629
50630
50631
50632
50633 <p><b>Proposed resolution:</b></p>
50634 Change the macro name to
50635 __STDCPP_THREADS__.
50636
50637
50638
50639
50640
50641 <hr>
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>
50648
50649 There is no way to join a thread with a timeout.
50650
50651 <p><i>[
50652 Resolution proposed by ballot comment:
50653 ]</i></p>
50654
50655 <blockquote>
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 
50658 timeout version.
50659 </blockquote>
50660
50661 <p><i>[
50662 2010 Batavia
50663 ]</i></p>
50664
50665 <p>
50666 The concurrency working group deemed this an extension beyond the scope of C++0x.
50667 </p>
50668 <p><b>Rationale:</b></p>The LWG does not wish to make a change at this time.
50669
50670
50671
50672 <p><b>Proposed resolution:</b></p>
50673
50674
50675
50676
50677
50678 <hr>
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>
50687
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.
50693
50694 <p><i>[
50695 Resolution proposed by ballot comment:
50696 ]</i></p>
50697
50698 <blockquote>
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.
50702 </blockquote>
50703
50704 <p><i>[
50705 2010 Batavia
50706 ]</i></p>
50707
50708 <p>
50709 The concurrency sub-group reviewed the options, and decided that closer harmony should wait until both standards are published.
50710 </p>
50711
50712 <p><b>Rationale:</b></p>
50713 The LWG does not wish to make any change at this time.
50714
50715
50716
50717
50718 <p><b>Proposed resolution:</b></p>
50719
50720
50721
50722
50723
50724 <hr>
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>
50733
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.
50737
50738 <p><i>[
50739 Resolution proposed by ballot comment:
50740 ]</i></p>
50741
50742 <blockquote>
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.
50755 </blockquote>
50756
50757
50758
50759 <p><b>Proposed resolution:</b></p>
50760
50761
50762
50763
50764
50765 <hr>
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>
50773
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>.
50778
50779 <p><i>[
50780 Resolution proposed by ballot comment:
50781 ]</i></p>
50782
50783 <blockquote>
50784 Add a member function:
50785 <pre>bool is_locked() const;
50786 </pre>
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).
50792 </blockquote>
50793
50794 <p><i>[
50795 2010 Batavia
50796 ]</i></p>
50797
50798 <p>
50799 The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x.
50800 </p>
50801
50802 <p><b>Rationale:</b></p>The LWG does not wish to make a change at this time.
50803
50804
50805
50806 <p><b>Proposed resolution:</b></p>
50807
50808
50809
50810
50811
50812 <hr>
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>
50820
50821 The condition variable <tt>wait_for</tt> returning <tt>cv_status</tt> is insufficient.
50822
50823 <p><i>[
50824 Resolution proposed by ballot comment:
50825 ]</i></p>
50826
50827 <blockquote>
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
50830 </blockquote>
50831
50832
50833
50834 <p><b>Proposed resolution:</b></p>
50835
50836
50837
50838
50839
50840 <hr>
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>
50848
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.
50855
50856 <p><i>[
50857 Resolution proposed by ballot comment:
50858 ]</i></p>
50859
50860 <blockquote>
50861 Remove the <tt>wait_until</tt> functions or make them at least conditionally supported.
50862 </blockquote>
50863
50864
50865 <p><b>Proposed resolution:</b></p>
50866
50867
50868
50869
50870
50871 <hr>
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>
50879
50880 Condition variables preclude a wakeup optimization.
50881
50882 <p><i>[
50883 Resolution proposed by ballot comment:
50884 ]</i></p>
50885
50886
50887 <blockquote>
50888 Change condition_variable to allow such
50889 optimization. See Appendix 1 - Additional Details
50890 </blockquote>
50891
50892 <p><i>[
50893 2010 Batavia
50894 ]</i></p>
50895
50896 <p>
50897 The Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x.
50898 </p>
50899
50900 <p><b>Rationale:</b></p>The LWG does not wish to make the change at this time.
50901
50902
50903
50904 <p><b>Proposed resolution:</b></p>
50905
50906
50907
50908
50909
50910 <hr>
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>
50918
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.
50922
50923 <p><i>[
50924 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50925 ]</i></p>
50926
50927
50928
50929
50930 <p><b>Proposed resolution:</b></p>
50931 Consider the removal of 'native_handle()'.
50932
50933
50934
50935
50936
50937 <hr>
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>
50946
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.
50950
50951 <p><i>[
50952 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
50953 ]</i></p>
50954
50955
50956
50957
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.
50962
50963
50964
50965
50966
50967 <hr>
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>
50975 <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>
50980 more than once.
50981 </p>
50982
50983 <p><i>[
50984 Resolution proposed by ballot comment:
50985 ]</i></p>
50986
50987 <p>
50988 Remove this note, or add words to the
50989 requirements for future that reflect what this note
50990 says.
50991 </p>
50992
50993
50994 <p><b>Proposed resolution:</b></p>
50995
50996
50997
50998
50999
51000 <hr>
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>
51008 <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>.
51013 </p>
51014
51015 <p><i>[
51016 Resolution proposed by ballot comment:
51017 ]</i></p>
51018
51019 <p>
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.
51022 </p>
51023
51024 <p><i>[
51025 2010-11-02 Daniel translates proposed changes into specific deltas and comments:
51026 ]</i></p>
51027
51028
51029 <blockquote>
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>.
51036 </blockquote>
51037
51038
51039
51040 <p><b>Proposed resolution:</b></p>
51041 <ol>
51042 <li>Change 30.6.7 [futures.shared_future]/3 as indicated:
51043 <blockquote>
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.
51047 </blockquote>
51048 </li>
51049 <li>Following 30.6.8 [futures.atomic_future]/2, add a new paragraph:
51050 <blockquote>
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>
51053 </blockquote>
51054 </li>
51055 </ol>
51056
51057
51058
51059
51060
51061 <hr>
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>
51069 <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
51077 value.
51078 </p>
51079
51080 <p><i>[
51081 Resolution proposed by ballot comment:
51082 ]</i></p>
51083
51084 <p>
51085 Make the move constructor for atomic future lock
51086 the source
51087 </p>
51088
51089
51090
51091 <p><b>Proposed resolution:</b></p>
51092
51093
51094
51095
51096
51097 <hr>
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>
51105 <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.
51114 </p>
51115
51116 <p><i>[
51117 Resolution proposed by ballot comment:
51118 ]</i></p>
51119
51120 <p>
51121 Decide whether the requirement is to block until
51122 finished or to call join, and rewrite to match.
51123 </p>
51124
51125
51126
51127 <p><b>Proposed resolution:</b></p>
51128
51129
51130
51131
51132
51133
51134
51135 </body></html>